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Introduction 



Las redes de ordenadores actuales son una amalgama de dispositivos, 
tecnicas y sistemas de comunicacion que han ido apareciendo desde fi- 
nales del sigloXIX o, lo que es lo mismo, desde la invencion del telefono. 

El telefono, que se desarrollo exclusivamente para transmitir voz, hoy se 
utiliza, en muchos casos, para conectar ordenadores entre si. Desde en- 
tonces han aparecido las redes locales, las conexiones de datos a larga 
distancia con enlaces transoceanicos o satelites, la telefonfa movil, etc. 

Mencion especial merece la red Internet dentro de este mundo de las co- 
municaciones a distancia. Nadie duda de que hoy en dfa constituye una 
red basica de comunicacion entre los humanos. 

Este curso ofrece una vision de las redes informaticas en general y de la 
red Internet en particular. 

En la primera parte, introduciremos las ideas y los conceptos basicos de 
las redes de ordenadores. Siguiendo un hilo historico, presentaremos 
los diferentes mecanismos que se han utilizado y se utilizan para comu- 
nicarse a distancia. Presentaremos igualmente el concepto de arquitec- 
tura de protocolos, fundamental en sistemas distribuidos, y el modelo de 
referencia OSI como un ejemplo paradigmatico de ello. Aunque hoy en 
dfa este modelo no disfruta de una gran popularidad, sus virtudes pe- 
dagogicas estan mas que demostradas: a partir de el es facil estudiar y 
entender otras arquitecturas, como la arquitectura Internet en torno a la 
cual gira todo el curso. 

La segunda parte esta dedicada al estudio de las redes de area local. 

Presentamos de forma descriptiva los diferentes tipos de redes que exis- 
ten, las ideas basicas de su funcionamiento y la nocion de cableado es- 
tructurado, clave en el gran auge que han tenido ultimamente las redes 
de area local. 

Nota 



En la tercera parte se veran los fundamentos de la red Internet. Lo 
que se conoce como red Internet es un conjunto heterogeneo de re- 
des interconectadas. Precisamente, es la capacidad de homogenei- 
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Internet es un apocope de 
internetworking (interconec- 
tando redes). 




zar lo que de hecho es heterogeneo, lo que ha catapultado la red 
Internet a su estatus actual. 



Nota 



Las RFC se pueden consul- 
tar en la siguiente direccion: 

http://www.ietf.org. 



Los protocolos que distinguen la red Internet como una unidad son 
el IP (Internet protocol) y el TCP ( Transmission control protocol ). Estos 
protocolos no son los unicos, pero sf los mas importantes de entre los 
que se necesitan para hacer funcionar la red Internet. Por este moti- 
vo, a todos en conjunto se les llama normalmentep/7a TCP/ IP (TCP/ 
IP stack). 

En concreto, en esta parte se describe el protocolo IP y sus mas inme- 
diatos colaboradores (ARP y ICMP), asi como los mecanismos de ac- 
ceso a Internet de que disponemos: a traves de una red de area local 
o un enlace telefonico, ya sea mediante PPP y un modem tradicional o, 
mas recientemente, mediante ADSL. 

TCP/IP no es un estandar de iure. Ningun organismo internacional 
de estandarizacion se ha encargado de emitirlo. Por el contrario, el 
funcionamiento de sus protocolos esta recogido en unos documentos 
llamados RFC (request for comments), que son propuestas que se han 
hecho sobre el funcionamiento de un protocolo concreto, o de una 
parte. El proceso es simple: una vez hecha publica una propuesta, si 
nadie pone ninguna objeccion, ya se considera aprobada y lista para 
ser implementada. 

Ademas de consultar este material didactico y la bibliograffa reco- 
mendada, en que se explican los protocolos de una forma pedago- 
gica, se recomienda leer alguna RFC, aunque solo sea para hacerse 
una idea del proceso que ha seguido la Red desde sus inicios 

En la cuarta parte, describiremos los protocolos de aplicacion mas 
utilizados actualmente en Internet y los programas mas habituales 
que los implementan, como son la conexion remota (telnet, rlogin), 
la transferencia de archivos (FTP), el correo electronico (SMTP, POP, 
IMAP), las news (NNTP), el WWW (HTTP) y la mensajerfa instantanea. 

Todos estos programas se conocen como aplicaciones distribuidas, 
puesto que estan formadas por distintas partes que pueden estar 
ejecutandose en maquinas diferentes. Esta dispersion de partes de 
programas obliga a definir una manera de dialogar entre ellas. 
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Veremos pues, antes de empezar la descripcion de las diferentes 
aplicaciones, este concepto de programacion distribuida y el mo- 
delo cliente/servidor que es el que sigue mayoritariamente. 

Las aplicaciones Internet permiten conocer las maquinas y los servi- 
cios a traves de nombres, y no con numeros que es como trabajan 
IP, TCP y UDP. Alguien tiene que encargarse de la asociacion de los 
nombres con las direcciones numericas y este alguien es el servicio 
DNS (Domain Name System). Tambien trateremos este tema antes de 
describir las aplicaciones. 
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Objetivos 



Con los materiales de este curso se pretende que el lector alcance los 
objetivos siguientes: 

1 . Conocer las diferentes tecnologias que se utilizan en la actuali- 
dad para transmitir informacion a distancia, y comprender 
cuando y por que aparecieron. 

2. Conocer el modelo de referenda OSI, sus utilidades y sus limita- 
ciones, y ser capaz de entender la motivacion de cada uno de 
sus niveles. 

3. Conocer los principios basicos de funcionamiento de las redes 
de area local tanto cableadas como inalambricas, las topologfas 
posibles y las diferentes politicos de acceso al medio. 

4. Conocer el concepto de cableado estructurado, entender el pa- 
pel que en el juegan los concentradores y saber diferenciar to- 
pologfa ffsica y topologfa logica. 

5. Entender los principios de funcionamiento del protocolo de nivel 
de red IP: la asignacion de direcciones y el direccionamiento. 

6. Aprender el funcionamiento de las redes de acceso a Internet 
mas comunes: acceso LAN y acceso per red telefonica mediante 
PPo ADSL. 

7. Entender el funcionamiento de los protocolos de transporte y sa- 
ber en que principios se basan. 

8. Conocer algunas utilidades de uso comun que permiten descubrir 
algunas interioridades de estos protocolos de red y transporte. 

9. Comprender el modelo cliente/servidor, que sirve como base de 
la implementacion de aplicaciones distribuidas y el modelo peer- 
to-peer, complementario del anterior. 

1 0. Comprender el funcionamiento del DNS, el servicio de nombres 
de dominio, que da soporte al resto de aplicaciones. 
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11. Conocer las aplicaciones telnet y rlogin, que proporcionan el 
servicio de conexion remota a otros ordenadores (principalmen- 
te en el entorno GNU/Linux), y las aplicaciones que proporcio- 
nan en Internet los servicios de transferencia de archivos, correo 
electronico, news, WWW y mensajena instantanea, y sobre todo 
los protocolos que siguen. 
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I. Introduccion a las redes 
de computadores 



1 . Breve historic! de las comunicaciones 



Desde que el ser humano tiene capacidad de comunicarse ha desa- 
rrollado mecanismos y sistemas que les permiten establecer esta co- 
municacion a distancias superiores de las alcanzadas por sus 
propios medios. 

Al poco de aparecer los ordenadores, se sintio la necesidad de inter- 
conectarlos para que se pudiesen comunicar entre si como lo hace- 
mos los humanos. 

En esta unidad nos planteamos repasar la historia de estos sistemas 
de comunicacion, pensados para ser usados por los humanos y que, 
despues, han ido evolucionando para interconectar ordenadores. 

Fijamos el inicio de este recorrido historico en el telefono. El telefono 
no fue el primer sistema de telecomunicacion, pero si el mas antiguo 
de los que hoy en dia se utilizan habitualmente. Mucho antes se ha- 
bian utilizado sistemas opticos que, con la luz del sol y juegos de es- 
pejos, permitian comunicarse desde distancias considerables. Con 
posterioridad, a mediados del siglo XIX, se invento el telegrafo. Estos 
sistemas, sin embargo, han caido en desuso (excepto usos margina- 
les), mientras que la red telefonica se mantiene como un sistema de 
comunicacion de primer orden. 



1.1. El telefono 



En 1878, Alexander Graham Bell mostro su "maquina electrica par- 
lante" y como podia mantener una conversacion a distancia entre 



dos de estos aparatos unidos por un hilo electrico. 


Nota 








Podeis encontrar la historia 






Nota 


completa de este episodio 






Recientes investigaciones han hecho salir a la luz una 
historia curiosa: parece claro que el inventor del tele- 


http://www.popular-science.net/ 

history/meucci_bell.html. 
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fono fue un italiano llamado Antonio Meucci, pero 
no patento su invento porque no tenia suficiente di- 
nero para hacerlo. Bell se apropio del invento y lo 
patento. 

Al principio, los pocos telefonos que existian se utilizaban en entornos 
cerrados, particulares. Servian para interconectar dos espacios. A medi- 
da que el numero de telefonos instalados crecia, el interes por mantener 
multiples comunicaciones tambien lo hacia: era preciso pensar en la 
manera de interconectarlos. Nacia la idea de red de comunicaciones. 

Una posible manera, bastante inmediata, de interconectar todos los 
aparatos seria lo que se puede observar en la figura siguiente: 




Es evidente que este modelo de conexion, "todos con todos", es com- 
pletamente inviable: para cada aparato nuevo que se incorpora a la 
red, se precisa un gran numero de conexiones nuevas. Para hacer- 
nos una idea, una red "todos con todos" de cincuenta telefonos ne- 
cesita 1.225 lineas de conexion y, en cada telefono, un dispositivo 
que permita cuarenta y nueve conexiones. 



Para solucionar este problema, aparecieron companias que ofrecian 
un servicio de commutacion: hacian llegar un cable hasta cada te- 
lefono y conectaban los cables de los telefonos que deseaban esta- 
blecer una comunicacion. De este modo, cada aparato disponia de 
una sola conexion y no era necesario establecer ninguna variacion en 
la misma para incorporar nuevos aparatos a la red. 
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Figura 2. 




De aqui provienen terminos hoy tan comunes comoabonado (el usuario 
que se abona a una central), bucle de abonado (el cable que une al 
abonado con la central) o central de conmutacion. 

La tarea de conmutar las conexiones, al principio, se hacia a mano. 
Cuando alguien queria realizar una llamada, descolgaba y pedia a la 
operadora que le conectara con quien deseaba hablar. Una vez finali- 
zada la comunicacion, la operadora desconectaba los cables y, asf, las 
lineas quedaban preparadas para recibir otras llamadas. 

Las operadoras humanas fueron sustituidas progresivamente por inge- 
nios electromecanicos: las centralitas. Se incorporo a los telefonos un 
disco con numeros para "marcar" el numero del destinatario de la 
llamada. La centralita descodificaba este numero para saber entre que 
dos cables era preciso establecer la comunicacion. 

Este servicio de conmutacion empezo en el ambito local: un barrio, un 
pueblo, una ciudad. El paso siguiente consistio en ofrecer conexiones a 
larga distancia, conectando centrales locales entre si directamente, o 
por medio de centrales de trafico. 



Figura 3. Comunicacion entre dos centrales de conmutacion 




Entre las dos centrales locales se establece un enlace con diferentes ca- 
bles independientes, de manera que los abonados de una de estas 
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pueden, ademas de conectarse entre ellos, conectar con los abonados 
de la otra: se elige un cable de los que forman el enlace, se conecta 
con el abonado local y se pide a la otra central que conecte el enlace 
con el abonado destino, si no esta ocupado con otra llamada. 

La conexion entre las dos centrales comporta un primer escollo impor- 
tante: es preciso decidir con cuantas lineas diferentes se llevara a cabo. 

Supongamos que la central A de la figura anterior proporciona servi- 
cio a cien abonados y la B, a doscientos cincuenta. Parece que, si se 
pretende dar el mejor servicio posible, se necesitan cien lineas para 
que todos los abonados de la central A puedan hablar de manera si- 
multanea con otros tantos de la central B. 



No obstante, la probabilidad de que todos los abonados de una cen- 
tral realicen una llamada al mismo momento es muy baja, puesto que 
las llamadas telefonicas son, en general, cortas y esporadicas. Por tan- 
to, es completamente innecesario que la conexion entre las dos cen- 
trales contemple todas las llamadas posibles: esta situacion no se dara 
nunca y tiene un coste exagerado. 



Nota 



A.K. Erlang, ingeniero danes 
de principios del siglo xx, es- 
tablecio los modelos mate- 
maticos que se utilizan para 
medir el trafico telefonico. 

Se puede encontrar mucha 
informacion al respecto en 
la direccion siguiente: 

http://www.erlang.com 



Unos modelos matematicos bastante complejos permiten calcular el 
numero concreto de enlaces que se precisan a partir de la estadistica 
de las llamadas que sirven las centrales (la frecuencia de aparicion y 
su duracion). 

Supongamos que en el ejemplo anterior estos modelos nos dan vein- 
ticinco enlaces. Si en un momento dado hay veinticinco llamadas en 
curso entre A y B y llega otra llamada, no tendra ningun camino dis- 
ponible y, por consiguiente, no se podra establecer. Esta situacion se 
denomina bloqueo: el abonado a quien se quiere llamar no esta ocu- 
pado; sin embargo, no se puede encontrar un camino libre por la red 
para establecer la comunicacion. 



De esta situacion se desprenden dos ideas fundamentales en re- 
lacion con la red telefonica: 

• La conmutacion de circuitos requiere pasar por tres fases para 
cada comunicacion: 

- Establecimiento de llamada. Cuando se solicita iniciar una con- 
versacion, es preciso averiguar si el destinatario esta disponible y, 
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en caso afirmativo, debe buscarse un camino libre en la red, que 
incluye conmutadores dentro de las centrales y enlaces entre las 
mismas. 

- Comunicacion. Una vez establecido el circuito, los interlocutores 
se intercambian informacion. 

- Liberacion de recursos. Acabada la comunicacion, se liberan los 
recursos utilizados (enlaces entre centrales y conmutadores dentro 
de las centrales). 

• El hecho de que los recursos esten ocupados en exclusiva mientras 
dura la comunicacion hace que las companfas que ofrecen el ser- 
vicio cobren segun la duracion de la llamada: se penaliza el uso 
extensivo de los recursos. De este modo, el usuario se apresura en 
acabar la comunicacion y dejar los enlaces libres, disminuyendo 
asf la probabilidad de bloqueo. 



La red telefonica constituye una red de conmutacion de 
circuitos. Para llevar a cabo una comunicacion, es pre- 
ciso establecer un circuito entre los dos extremos por 
medio de la red. Mientras dura la comunicacion, se 
ocupan unos recursos en exclusiva, aunque no haya in- 
tercambio de informacion. Las companfas cobran el 
uso de los recursos por tiempo de ocupacion. 



Pronto, el sistema telefonico paso a ser una cuestion nacional. Los 
estados desarrollaban sus redes segun sus criterios y gustos. Se 
creo un organismo, el CCITT (Comite Consultivo Internacional de 
Telegraffa y Telefonfa, Comite Consultatif International Telegraphique 
et Telephonique), para armonizar los sistemas nacionales y permitir 
las comunicaciones entre pafses mediante centrales de trafico inter- 
nacionales. 



Nota 



El CCITT es un organismo in- 
ternacional patrocinado por 
las operadoras de telefonfa, 
dedicado a tareas de norma- 
lizacion en el ambito de las 
telecomunicaciones. El 1 de 
marzo de 1993 paso a lla- 
marse ITU-T (International 
Telecommunication Union 
Standardisation Sector). 



Hemos comentado que entre las centrales existe una serie de If- 
neas que permiten la conexion entre abonados de diferentes cen- 
trales. Al principio era realmente asf: si se decidfa que entre dos 
centrales era preciso disponer de cincuenta enlaces, se ponfan 
cincuenta cables entre ellas. Sin embargo, con el progresivo aumento 
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Nota 



Multiplexor significa hacer 
pasar diferentes comunica- 
ciones independientes por el 
mismo medio de transmi- 
sion. 



de enlaces necesarios, este sistema pronto fue totalmente inviable 
y fue preciso recurrir a una tecnica ya conocida en radiodifusion: 
la multiplexacion. 

La tecnica de multiplexacion que se aplico a la telefoma fue la mul- 
tiplexacion en frecuencia: se modulan los diferentes canales de en- 
trada a distintas frecuencias portadoras, de manera que puedan 
viajar por el mismo medio sin interferirse. Se aplican filtros a la re- 
cepcion que permiten separar los distintos canales multiplexados. 



Ejemplo 

Hacemos lo mismo al escuchar la radio o al ver la te- 
levision. Hasta nuestra antena llegan todos los canales 
emitidos; con el dial y el selector de canales, respecti- 
vamente, seleccionamos el canal (la gama de frecuen- 
cias) correspondiente a la emisora que queremos 
recibir. Es decir, el dial o el selector de canales de la te- 
levision constituyen los filtros que separan, en la recep- 
cion, los diferentes canales multiplexados. 



El numero de canales diferentes que pueden viajar por un medio multi- 
plexado depende del ancho de banda de la serial y de la capacidad del 
medio. 

Por lo que respecta a la capacidad del medio, no posee la misma un 
par de hilos que un cable coaxial o que una fibra optica. 

En cuanto al ancho de banda, en el caso de la voz, deberfa ser 
de 1 9.980 Hz (que es un ancho de banda considerable) puesto que 
el ofdo humano es capaz de distinguir frecuencias entre los 20 Hz y 
los 20.000 Hz. No obstante, a ratz de estudios que se llevaron a cabo 
sobre las caractensticas de la voz humana, se llego a la conclusion 
de que con mucho menos bastaba, puesto que la inteligibilidad de la 
voz se concentra en una banda bastante estrecha, entre los 300 Hzy 
los 3.400 Hz. 

A partir de esta conclusion, se tomo una decision que, a la larga, ha 
condicionado mucho el uso de la red telefonica: hacer el canal de voz 
de 4 kHz (entre 300 Hz y 3.400 Hz, mas unas bandas laterales de 
guardia). 



24 




Nota 

Haber reducido el canal de voz a 4 kHz explica por 
que se escucha tan mal la musica por el telefono: no 
hay ni graves ni agudos, solo hay las frecuencias del 
medio. 

A partir de aquf, se estandarizaron los diferentes niveles de mul- 
tiplexacion. El nivel basico es la agrupacion de distintos canales 
de 4 kHz, el siguiente es una agrupacion de multiplexados basi- 
cos, etc. 



Nota 

La jerarquta que propuso la compama americana AT&T, 
y que ha acabado estandarizandose, es la siguiente: 



Tabla 1. 



Nombre 


Rango 


Ancho 
de banda 


Canales 
de voz 


Group 


60-108 kHz 


48 kHz 


12 


Supergroup 


312-552 kHz 


240 kHz 


60 


Mastergroup 


564-3.084 kHz 


2,52 MHz 


600 


Jumbogroup 


0,5-17,5 MHz 


17 MHz 


3.600 



A la entrada de la central local se encuentra un filtro que elimina 
cualquier frecuencia por encima de los 4 kHz. La serial de salida 
de este ultimo es la que se multiplexa, conmuta y lleva hasta el 
destinatario. 
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Nota 



Al decir que eran maquinas 
poco potentes, evidentemen- 
te, es comparadolos con los 
actuales. Para la epoca, eran 
unas maquinas fantasticas. 



Nota 



A los terminales pasivos, que 
coloquialmente se llaman ter- 
minales tontos , en ingles se les 
conoce como dumb terminal 
('terminal mudo'). 



Con todo ello, ya podemos dibujar un panorama completo de la 
red telefonica, tal como era hasta los anos setenta: 



La red telefonica es analogica, ubicua, trabaja con la 
tecnica de conmutacion de circuitos, con tarifacion 
por tiempo de ocupacion, con enlaces multiplexados 
en frecuencia y con canales limitados a 4 kHz. 



1 .2. Aparecen los primeros ordenadores 



La decada de los sesenta vio la aparicion de los primeros ordena- 
dores comerciales. Eran grandes, caros y poco potentes. Solo or- 
ganismos oficiales, grandes empresas o universidades podfan 
comprarlo, y lo que es mas normal es que solo compraran uno (o 
algunos, pero no uno para cada usuario, como hoy dta estamos 
acostumbrados a ver). 

Por ello, estos ordenadores llevaban sistemas operativos multita- 
rea y multiusuario, para que diferentes usuarios, realizando dis- 
tintos trabajos, pudieran utilizarlos simultaneamente. El acceso a 
dichos ordenadores se llevaba a cabo por medio de terminales sin 
ninguna capacidad de proceso, pasivos: 



Figura 5. 
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1 .2.1 . Los modems 



No tardo mucho en aparecer la necesidad de poder alejar los termi- 
nales de la unidad central para conectarse, por ejemplo, desde casa 
o desde una delegacion al ordenador central. 

Para poder realizar este acceso remoto, la primera solucion que apor- 
taron los ingenieros informaticos de la epoca fue utilizar la red telefonica 
que, por su ubicuidad, les ahorraba generar infraestructuras nuevas. 
Solo se precisaba un aparato que adaptara los bits a la red (recordad 
que la red telefonica solo deja pasar sonidos entre unos margenes de 
frecuencia). Estos aparatos son los modems. 



Nota 



Modem es un acronimo de 
modulator-demodulator, que 
se refiere a su funcion: modu- 
lar (generar senales audibles 
segun los valores de los bits) 
y demodular (generar bits a 
partir de las senales que reci- 
be de la red telefonica). 




Los primeros modems eran de 300 bps y generaban dos tonos di- 
ferentes: uno para el 1 logico y otro para el 0. En la actualidad, 
van a 56.000 bps, que es el maximo que permite la red telefonica 
convencional actual. 



Los 56.000 bps (56 k) de velocidad de transmision solo 
se puede lograr si uno de los dos extremos tiene una 
conexion especial con su centralita, (la mayona de los 
proveedores de Internet la tiene). De hecho, con Ifneas 
telefonicas convencionales, la velocidad maxima es de 
33.600 bps. 
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Los modems no solo Servian para poder alejar los terminales pa- 
sivos de los ordenadores centrales, tambien permitian interconec- 
tar ordenadores entre si. 




iEsto ya es una red de computadores! 

La tecnologfa de conmutacion de circuitos se desarrollo en un origen 
para las comunicaciones telefonicas y una de sus caracterfsticas fun- 
damentales era la ocupacion en exclusiva de los recursos mientras 
duraba la conexion, lo que (como ya hemos visto) justificaba la tari- 
facion portiempo. Sin embargo, las comunicaciones informaticas no 
son cortas, intensas y esporadicas como las de voz. Al conectar un ter- 
minal a un ordenador central por medio de dos modems, no estan pa- 
sando datos todo el tiempo que dura la conexion: puede haber 
largos periodos de tiempo en los que no pase ningun bit y momentos 
en los que haya un intercambio de datos intenso, aunque a una ve- 
locidad de transmision mucho mas baja que la que se puede man- 
tener entre el terminal y el ordenador conectados directamente. Las 
facturas telefonicas empezaron a ser astronomicas, y desproporcio- 
nadas, respecto del uso real de la red. 



1.2.2. Las redes de datos 

Pronto las grandes empresas presionaron a las companias telefoni- 
cas del momento para que desarrollaran redes pensadas para trans- 
porter datos, cuyo sistema de tarifacion se ajustara al trafico de datos 
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real y permitiera mas velocidad que los escasos 300 o 1 .200 bps que 
se lograban utilizando la red telefonica. La respuesta fueron las re- 
des de conmutacion de paquetes. 

El envfo de datos no necesariamente debe llevarse a cabo en tiempo 
real (las transmisiones de voz, si). Por tanto, no es preciso establecer 
el camino entre los dos puntos antes de empezar la transmision y 
mantenerlo mientras dura el intercambio de datos. En lugar de ello, 
se empaquetan los bits que deben transmitirse y se dan a la central 
mas proximo para que los envfe cuando pueda a la siguiente, y asf 
sucesivamente hasta que lleguen al destino. Si cuando un paquete 
llega a una central todos los enlaces con la siguiente estan ocupados, 
no pasa nada, lo hace esperar poniendolo en una cola para enviarlo 
cuando haya un enlace disponible. 



La transmision por paquetes tiene la ventaja de que 
solo ocupa los recursos cuando en realidad se utilizan, 
no siempre. Sin embargo, como contrapartida, es 
preciso soportar el retardo que pueda producirse entre 
que los paquetes salen del origen y llegan a su destino, 
que es variable, puesto que las esperas en las colas 
son aleatorias, dependen del estado de la red. Pero, 
como hemos dicho, en comunicacion de datos este 
retardo es hasta cierto punto tolerable. Por lo que 
respecta a la cuestion economica, no tiene sentido 
que se cobre por tiempo de conexion: en las redes de 
datos se paga por bits transmitidos. 



Existe otro peligro: los paquetes pueden perderse. Conviene tener 
presente que las colas son limitadas y, si llega un paquete cuando 
una ya esta llena, no se podra guardar y se perdera. Es preciso pre- 
ver mecanismos que eviten dichas perdidas y regulen el flu jo de in- 
formacion entre los nodos de conmutacion. 



Nota 



En Espana, la red de datos 
se llamaba Iberpac. 

En ia actualidad, para co- 
municaciones de datos se 
utiliza Frame Relay, la evo- 
lucion natural de X.25. 



Las compamas telefonicas desarrollaron redes de este tipo, y el 
CCITT emitio un estandar, el X.25, que es el que se ha adoptado has- 
ta hace muy poco. 
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1.2.3. Las redes de area local 



Nota 



Con frecuencia se utiliza la 
sigla inglesa LAN ( local 
area network ) para identifi- 
car las redes de area local, 
y la sigla WAN favide area 
network ) para identificar las 
redes de gran alcance. 



Cuando empezo a ser habitual disponer de mas de un ordenador 
en la misma instalacion, aparecio la necesidad de interconectar- 
los para poder compartir los diferentes recursos: dispositivos caros, 
tales como impresoras de calidad, un disco duro que almacenara 
los datos de la empresa, un equipo de cinta para realizar copias 
de seguridad, etc. 



El diseno de las redes de area local siguio caminos completamente 
diferentes de los que se siguieron para las redes de gran alcance. En 
las redes de area local se necesita, habitualmente, establecer comu- 
nicaciones "muchos a uno" y "uno a muchos", lo que es diffcil de con- 
seguir con las redes de conmutacion, pensadas para interconectar 
dos estaciones. Para este tipo de redes es mas adecuada la difusion 
con medio compartido, en que los paquetes que salen de una esta- 
cion llegan a todo el resto simultaneamente. En la recepcion, las es- 
taciones los aceptan o ignoran dependiendo de si son destinatarias 
delos mismos o no. 



Difusion con medio compartido 



Se habla de difusion porque los paquetes se difunden 
por todos lados, y de medio compartido porque esta ul- 
tima se Neva a cabo sobre un medio comun que las es- 
taciones comparten. 



1 .3. Arquitecturas de protocolos 

De la decada de los sesenta datan tambien los primeros estanda- 
res de arquitecturas de protocolos. Conviene tener presente que 
el intercambio de informacion entre ordenadores tiene toda una 
serie de implicaciones, entre las que se encuentran las siguientes: 

• Aspectos electricos: los cables, los conectores, las senales, etc. 

• La manera de agrupar los bits para formar paquetes y la de con- 
trolar que no se produzcan errores de transmision. 
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• La identificacion de los ordenadores dentro de la red y la manera 
de conseguir que la informacion que genera un ordenador llegue 
a quien se pretende. 

Atacartodos estos aspectos de una manera global no es viable: dema- 
siadas cosas y demasiado diferentes entre si. Por ello, ya desde el prin- 
cipio, se desarrollaron modelos estructurados en niveles: en cada nivel 
se lleva a cabo una tarea y la cooperacion de todos los niveles propor- 
ciona la conectividad deseada por los usuarios. 

Conviene considerar que, en la epoca que nos ocupa, la informatica es- 
taba en manos de muy pocos fabricantes e imperaba la filosoffa del ser- 
vicio integral: cada fabricante lo proporcionaba todo (ordenadores, 
cables, perifericos, sistema operativo y software). Por tanto, cuando 
una empresa se querfa informatizar, elegfa una marca y quedaba 
vinculada a la misma para toda la vida. 



Nota 

Hablamos de empresas como IBM (International Business 
Machines) o DEC (Digital Equipment Corporation). 
Cuando estas empresaas se propusieron ofrecer co- 
nectividad entre sus equipos, local o remota, tambien 
lo hicieron aplicando la filosoffa de la separacion por 
niveles: IBM desarrollo la arquitectura SNA System 
network arquitecture) y DEC, la DNA (DEC network 
arquitecture ). Eran dos modelos completos, estructu- 
rados en niveles, pero incompatibles entre sf, segun la 
filosoffa de la informatica propietaria. 



En la decada de los setenta el panorama cambio radicalmente, so- 
bre todo a causa de tres acontecimientos: 



• La propuesta del protocolo Ethernet para redes locales. 

• La aparicion del sistema operativo Unix, que no estaba vinculado 
a ninguna marca comercial, compatible con todas las platafor- 
mas de hardware existentes. 

• La invencion de los protocolos TCP/IP, embrion de la actual Internet. 



Nota 



TCP/IP son las siglas de 
transmission control protocol/ 
Internet protocol (protocolo 
de control de transmision/ 
protocolo de Internet). 



Se habfa allanado el camino para la aparicion de los sistemas abier- 
tos: no era preciso vincularse a ninguna marca para tenerlo todo. El 
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hardware podia ser de un proveedor, el sistema operativo de otro, 
las aplicaciones de otro y los protocolos, publicos. 

TCP/IP nacio a partir de un encargo de la DARPA a la comunidad 
cientifica americana para obtener una red mundial que fuera recon- 
figurable con facilidad y de forma automatica en caso de destruccion 
de algun nodo o de algun enlace. 



La pila TCP/IP era una jerarquia de protocolos que ofrecfa conectivi- 
dad y, a pesar de tener poco que ver con las que ya existian, consti- 
tute una opcion mas en el mercado. Ante una oferta tan grande y 
dispar de protocolos, la ISO (Organizacion Internacional de Estan- 
darizacion, International Organization for Standardization) y el 
CCITT propusieron un nuevo modelo que intentaba reunir de algun 
modo todo lo que ya se habia propuesto y que pretendia ser comple- 
to, racional y muy bien estructurado (la TCP/IP tiene fama de ser una 
pila de protocolos anarquica), con la intencion, portanto, de que se 
convirtiera en un modelo de referencia. Es la conocida como pila de 
protocolos OSI ( open systems interconnection ). 




Internet, que nacio y credo en las universidades, se 
empezo a popularizar en la decada de los noventa, 
a medida que quienes conocian la Red la iban "en- 
senando", y su eclosion se produjo cuando salto al 
mundo de la empresa, en todas sus vertientes: como 
escaparate de productos o como canalizador de con- 
tactos comerciales. 



Sin embargo, el origen universitario de la Red ha marcado su evo- 
lucion en muchos sentidos. Por ejemplo, el modelo cliente/servidor 
de aplicaciones distribuidas. Es un modelo sencillo y, al mismo 
tiempo, potente, y casi todas las aplicaciones que se utilizan en In- 
ternet lo siguen. El Telnet, o apertura de sesion remota, la trans- 
ferencia de ficheros (FTP), el correo electronico y, sobre todo, el 
WWW (World Wide Web) constituyen ejemplos claros de aplica- 
ciones que siguen este modelo. Las dos primeras han caido un 
poco en desuso, pero tanto el correo como el WWW son las ac- 



32 



tuales estrellas en Internet. Timidamente, aparecen nuevas pro- 
puestas de aplicaciones; sin embargo, el WWW, que nacio como 
un servicio de paginas estaticas enlazadas con hiperenlaces, se 
esta convirtiendo en la interfaz de usuario de toda la Red, puesto 
que en la actualidad se utiliza para servir paginas dinamicas (se 
crean en el momento en que se sirven), e, incluso, codigo que se 
ejecuta en el ordenador cliente (applets). 



1.4. La digitalizacion de la red telefonica 



En este momento tenemos dos redes completamente independientes 
entre si, pero de alguna manera superpuestas: 

• Una red analogica, con conmutacion de circuitos, pensada para voz. 

• Una red digital, con conmutacion de paquetes, pensada para datos. 

La red telefonica, tal como la hemos descrito hasta ahora, es com- 
pletamente analogica: la serial electromagnetica que viaja desde 
un telefono hasta otro es analogica (varfa continuamente y en 
cualquier momento puede adoptar cualquier valor) y los circuitos 
electronicos que componen la red tambien lo son. 

Los enlaces entre centrales de la red telefonica se llevaban a cabo 
con senales analogicas con muchos canales multiplexados en fre- 
cuencia y, en ocasiones, debfan recorrer grandes distancias. La 
atenuacion de la serial inherente a la distancia que era preciso re- 
correr debfa corregirse por medio de repetidores que la amplificaban, 
lo que aumentaba el ruido presente en la linea. A menudo, la serial re- 
cibida era de una calidad muy baja porque la transmision analogica 
no permite eliminar el ruido y las interferencias en la recepcion. 
No hay manera de saber con exactitud que se ha enviado desde el 
origen y que es ruido anadido. 

En 1972, se hicieron publicos los primeros resultados del trata- 
miento digital de la serial aplicado a audio, basicamente orienta- 
do a su almacenamiento. El CD estaba viendo la luz. Convertir un 
sonido (una magnitud ffsica que puede adoptar cualquier valor en 
cualquier momento) en una serie de 0 y 1 (dos unicos valores, co- 
nocidos) permitfa corregir con facilidad cualquier ruido anadido. 
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Figura 8. 




En el caso de la serial analogica, viendo la serial recibida, no se puede deducir cual ha 
sido la serial emitida. En cambio, en el caso de la serial digital, como se conocen los va- 
lores enviados, se establece un umbral en el punto medio entre los dos valores y se decide 
que todo lo que este por encima corresponde a un 1 y todo lo que este por debajo, a un 0. 
Si el ruido que se ha anadido es superior a la diferencia entre el valor original y el umbral, 
se produce un error de recepcion: se decide que se habia enviado el valor equivocado. 
Las tecnicas para luchar contra este tipo de errores se veran mas adelante. 



El descubrimiento del procesado digital de la serial, asf como sus 
aplicaciones en los campos del sonido y la imagen, ha constituido un 
hito capital en el mundo de las comunicaciones. Basicamente, ha 
permitido reducir drasticamente el efecto del ruido, lo que ha posibi- 
litado, por un lado, incrementar la calidad de recepcion de las sena- 
les y, por el otro, aumentar la velocidad de transmision con los 
mismos medios. 



Las companias telefonicas empezaron a sustituir los enlaces internos 
(entre centrales) por senales digitales, pero manteniendo el bucle de 
abonado (Ifnea y terminal) analogico. La digitalizacion de la serial 
de sonido se lleva a cabo dentro de la central local, despues del 
filtro de 4 kHz, y se vuelve a pasar a analogica en la central correspon- 
diente al otro extremo de la comunicacion. La digitalizacion ha hecho 
cambiar sustancialmente los procesos de commutacion: ahora debe tra- 
bajarse con bits y, por tanto, las centrales electromecanicas deben sus- 
tituirse por ordenadores. 



digitalizacion de la parte interna de la red de voz 
hizo que, de algun modo, las dos redes, la telefonica y 
la de datos, confluyeran: los enlaces digitales entre 
centrales se utilizaban indistintamente para paquetes 
de datos y para transmisiones de voz. 
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1.4.1. La red digital de servicios integrados 



Una vez digitalizada la red telefonica, el paso siguiente debia ser 
llevar la transmision de bits hasta las casas. Elio permitfa, por un 
lado, ofrecer a los usuarios en su casa la transmision de datos 
ademas de la tradicional de voz y, por otro, ofrecer a los abona- 
dos un abanico de nuevos servicios asociados a una comunica- 
cion enteramente digital de extremo a extremo. Este servicio de 
transmision digital por medio de la red telefonica se conoce como 
red digital de servicios integrados (RDSI). Ofrece dos canales inde- 
pendientes de 64 kbps, que permiten hablar y conectarse a Internet 
simultaneamente, o, con el hardware adecuado, aprovechar los dos 
canales juntos para navegar a 128 kbps. 



Nota 



La red digital de servicios in- 
tegrados (RDSI) corresponde 
a las siglas en ingles ISDN 
( integrated services digital 
network ) . 



1.5. La banda ancha 



El uso de la red telefonica para transmitir datos tiene una limitacion im- 
portante por lo que respecta al maximo de bits por segundo permitidos 
y las redes especfficas de datos son muy caras para el uso domestico. 
Desde la decada de los noventa, se han estudiado maneras de llevar 
hasta las casas o las empresas un buen caudal de bits por segundo 
(banda ancha) a un precio razonable, de manera que las nuevas apli- 
caciones multimedia se puedan explotar al maximo. 

Para conseguir esta banda ancha, se han seguido dos caminos comple- 
tamente diferentes: 

• Se han promovido cableados nuevos con fibra optica que permitan 
este gran caudal, con frecuencia implementados por empresas con 
afan competidor contra los monopolios dominantes. Estas redes se 
aprovechan para proporcionar un servicio integral: television, telefo- 
no y datos. 

• Las compamas telefonicas de toda la vida han querido sacar partido 
del cableado que ya tienen hecho y, por el lo, se han desarrollado las 
tecnologias ADSL, que permiten la convivencia en el bucle de abo- 
nado de la serial telefonica y una serial de datos que puede llegar a 
los 8 Mbps. 
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Not a 



La frontera entre banda estrecha y banda ancha no 
esta muy clara. Los 1 28 kbps de la RDSI se consideran 
banda estrecha y, hay quien califica de banda ancha 
a los 256 kbps de la ADSL basica. 

Realmente, se considera banda ancha a partirde 1 Mbps. 



| 1 .6. La telefoma movil 

La telefoma movil, todo un fenomeno sociologico de finales del si- 
glo xx, ha vivido una evolucion fulgurante: en menos de veinte anos, 
ha pasado de la nada a constituir una tecnologia de uso diario para 
mas de un 70% de la poblacion. 



Desde el punto de vista de sistema de comunicacion, debemos ver 
los moviles como una extension de la red telefonica convencional. 



Figura 9. 
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El sistema GSM, que constituye el actual estandar europeo, permite 
el acceso a la red de voz, cambiando el bucle de abonado: en lugar 
de ser un cable, es un enlace radioelectrico entre una antena y el mo- 
vil. Se trata, por tanto, de una red de conmutacion de circuitos y se 
continua fijando la tarifa por tiempo de conexion. 
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El estandar GPRS permite el transporte de bits, pagando por trafico 
en lugar de por tiempo. Por tanto, es aproximadamente el clonico de 
las redes de datos con hilos. 





El estandar UMTS, en la actualidad todavfa en la fase previa a su lan- 
zamiento comercial, permite transferencias del orden de megabits 
por segundo, necesarias para disponer de aplicaciones multimedia 
en el movil. Sin embargo, requiere nuevas antenas y terminales. 
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2. Arquitecturas de protocolos: el modelo OSI 



Como ya hemos comentado, cuando el CCITT y la ISO propusieron 
la torre OSI, en el mercado habfa muchas arquitecturas de protoco- 
los, unas propietarias, otras abiertas, pero todas diferentes. La torre 
OSI pretendfa ser un modelo basico de referenda, un marco para el 
desarrollo de estandares que permitieran la interoperabilidad com- 
pleta. Diferentes razones han hecho que este modelo, asf como las 
normas que del mismo se derivan, no hayan tenido la repercusion que 
se esperaba, entre las que destacan las siguientes: 

• La complejidad del modelo, innecesaria en muchos casos. 

• La complejidad de las normas desarrolladas a partir del modelo. 

• El impulso del modelo Internet y la simplicidad de sus estandares. 

A pesar de que el modelo OSI no se haya impuesto en los desarro- 
llos, es muy util como referencia para explicar que debe hacerse y co- 
mo. El hecho de que sea tan completo y cartesiano lo hace muy 
interesante para la pedagogfa de los conceptos basicos de redes, y 
las arquitecturas que en realidad se utilizan se explican estableciendo 
una relacion constante con el modelo OSI. Por ello, en este apartado 
explicamos los siete niveles de la torre OSI. A partir del modulo si- 
guiente, sin embargo, nos centraremos en la arquitectura TCP/IP, la 
que constituye la Red Internet. 



2.1 . Definicion 



El modelo basico de referencia OSI, o simplemente 
modelo OSI, afronta el problema de las comunicacio- 
nes de datos y las redes informaticas dividiendolo en 
niveles. Cada participante de la comunicacion incorpo- 
ra como mfnimo uno de los mismos, y los equipos ter- 
minales los incorporan todos. 
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Equipo A 



Equipo B 



Figura 10. 




Los niveles de la torre se comunican en dos direcciones: 

• Horizontal. La comunicacion horizontal solo se da entre niveles ho- 
monimos. Se podrfa pensar -y de hecho es asi- que todo el nivel 
constituye un unico sistema distribuido que tiene un representante en 
cada uno de los equipos. Un protocolo de nivel i (en el que i es el 
identificador del nivel correspondiente) especifica el formato, el sig- 
nificado y la temporizacion de la informacion que circula entre los 
miembros de este sistema distribuido. 

• Vertical. La comunicacion vertical solo se da entre niveles adyacentes 
de un mismo sistema. Este tipo de comunicacion posee un caracter 
totalmente local; es decir, puede materializarse por mecanismos de 
software (llamadas a liberfas, comunicacion entre procesos, etc.). De 
manera generica, denominaremos estos mecanismos servicio de ni- 
vel i (en el que / es el identificador del nivel que proporciona el ser- 
vicio, e / + 1 , el nivel que lo utiliza). 



2.2. Los protocolos 



Con los protocolos se pretende la intercomunicacion de entidades si- 
tuadas en diferentes maquinas. Entendemos por entidad un sistema 
electronico y/o informatico, ubicado dentro de un nivel del modelo OSI, 

40 











que, en combinacion con las otras entidades del mismo nivel situa- 
das en otros sistemas, forma un todo (un sistema distribuido). 

Portanto, laespecificacion del protocoloque utilizamos debe llevar- 
se a cabo en un estandarclaramente definido que permita a desarro- 
lladores que no trabajan juntos implementarlo de manera totalmente 
identica. 

La recepcion de una secuencia de bits en un momento inesperado o 
de una longitud incorrecta, o en una disposicion imprevista, puede 
hacer que la entidad destinataria no reaccione correctamente y deje 
de inmediato el nivel (las dos entidades que lo forman) en una situa- 
cion inestable. 

Evidentemente, esta situcion no se puede permitir. Por ello, la imple- 
mentacion del protocolo debe ser extremamente esmerada y, por 
consiguiente, tambien la especificacion del estandar. 




Figura 1 1 . 



Prolocolos 




Protocolo de 
nivel i + 1 



Protocolo 
nivel i 



Protocolo de 
nivel i — 1 
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2.3. Los servicios 



Nota 



En terminologia OSI se sue- 
le decir que los servicios no 
se especifican, sino que se 
describen. 



La especificacion de un servicio es siempre menos estricta que la de 
un protocolo. Por servicio entendemos la comunicacion que se pro- 
duce dentro de una misma maquina y, por consiguiente, dentro de 
un unico ambito de responsabilidad. La funcionalidad de las interfa- 
ces de cada uno de los niveles (y, por tanto, de las entidades que la 
implementan), la determinaran los estandares que utilicen; sin em- 
bargo, su especificacion precisa no es relevante para los estandares 
involucrados. Cada sistema individual puede materializarlas de una 
manera u otra segun convenga. 



Sea como sea, la cantidad de papel que ocupa la descripcion de un 
servicio siempre sera muy inferior a la que ocupa la especificacion de 
un protocolo. 




Actividad 

Comentad las diferencias existentes entre protocolo y 
servicio. 
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2.4. Los siete niveles del modelo OSI 



2.4.1 . Nivel fisico 

El nivel fisico se encarga de las tareas de transmision fisica de las se- 
nales electricas (o electromagneticas) entre los diferentes sistemas. 
Las limitaciones del nivel fisico (equipos de transmision y recepcion, 
medios de transmision, amplificadores, etc.) imponen otras al resto 
del sistema: por un lado, limitan la velocidad de transmision (en bits 
por segundo) y, por otro, hacen aparecer una probabilidad de 
error, el porcentaje de bits erroneos que llegan a destino. 



La primera limitacion es casi insalvable partiendo de un medio de 
transmision dado, puesto que los parametros fisicos de este ultimo 
imponen un limite superior no superable por medio de una mejora 
tecnologica. Los medios de transmision poseen una capacidad de 
transmision acotada y la electronica que utilizamos para llevar a 
cabo las transmisiones puede mejorar la velocidad de transmision, 
pero no superar este limite. Esta limitacion viene dada por el ancho 
de banda, o anchura del espectro electrico, que puede atravesar el 
medio de transmision (doblar el ancho de banda significa que se 
puede doblar la velocidad de transmision) y por la imposibilidad 
practica de recibir la serial libre de cualquier interferencia. 



Nota 



En el nivel fisico somos inca- 
paces de corregir errores. 
Asumimos una probabilidad 
de error y encargamos al nivel 
superior su correccion. 



2.4.2. Nivel de enlace 

El nivel de enlace es el primero de la torre OSI que se basa en software, 
algoritmos y protocolos. Su mision principal es dar fiabilidad a la 
transmision de las senales electricas o electromagneticas que pro- 
porciona el nivel fisico, lo que se puede conseguir si las cotas de error 
son inferiores al 1%. Se anaden bits adicionales a los que forman el 
mensaje para poder detector errores de transmision y pedir su re- 
transmision. Para el lo, es preciso conferir una estructura a los bits: se 
agrupan en pequenos bloques denominados tramas, que contienen 
los bits de mensaje, los bits anadidos para detector errores y diferen- 
tes campos de control, tales como el numero de trama. 



Nota 



El hecho de que las tramas 
sean pequenos bloques de 
bits minimiza la probabili- 
dad de que haya muchos 
bits erroneos dentro de los 
bloques. 



El transmisor calcula estos bits adicionales a partir del resto por me- 
dio de una operacion que el receptor conoce y aplica igualmente. Si 
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el receptor detecta una discrepancia entre los bits adicionales (redun- 
dantes) y los que ha calculado a partir del resto, detecta que el blo- 
que es erroneo y pedira su retransmision. 



adicion de los bits redundantes y su comparacion en 
recepcion se denomina deteccion de errores. Los pro- 
cedimientos de correccion a partir de dicha deteccion 
se conocen como control de errores. 



Ademas del control de errores, el nivel de enlace lleva a cabo otra 
tarea importante: el control de flu/o. 



El receptor debe procesar las tramas a medida que las recibe. En al- 
gunos casos, este proceso comporta un gasto de tiempo mmimo, te- 
niendo en cuenta la velocidad de transmision (por ejemplo, guardar 
los datos en disco); sin embargo, puede haber casos en que este pro- 
ceso sea costoso. En esta situacion, el receptor necesita un mecanis- 
mo que notifique al transmisor que debe detener momentaneamente 
la transmision con el objetivo de disponer del tiempo necesario para 
llevar a cabo esta tarea. 

El nivel de enlace no solo sirve para controlar Ifneas punto a punto, 
sino tambien para controlar Ifneas compartidas por diferentes termi- 
nales (redes de area local). 



2.4.3. Nivel de red 

El nivel de red es el que permite que pueda haber mas de dos ma- 
quinas involucradas en las inerconexiones. Si solo se tuviese el nivel 
de enlace, esto no serfa posible. El nivel de enlace se ocupa de que 
los bits lleguen de una lado a otro, por lo tanto, solo permite inter- 
conectar dos maquinas. Para poder interconectar mas de dos maqui- 
nas, necesitamos identificarlas y conectarlas de alguna manera. Esta 
es la tarea del nivel de red. 

Ya hemos visto que las redes de conmutacion de paquetes constitu- 
yen el tipo de red mas eficiente para transmitir datos desde diferentes 




puntos de vista: uso de recursos, coste, capacidad de mantener dis- 
tintas conexiones simultaneas, etc. El modelo OSI, portanto, solo ha- 
bla de redes de conmutacion de paquetes. 

En el nivel de red se distingue entre estaciones terminales y nodos de 
conmutacion: 



Figura 13. 




La palabra red proviene de esta imagen: los enlaces 
son los cordeles que unen los nudos o sistemas. 



Los nodos de conmutacion disponen de diferentes enlaces hacia 
otros nodos o hacia terminales, y son los que permiten que los pa- 
quetes viajen por la red desde una estacion terminal a otra. 



Existen dos tipos de redes de conmutacion de paquetes: 



• Redes que funcionan en modo datagrama. Podriamos decir que 
este tipo de redes son las basicas, puesto que incorporan la funcio- 
nalidad minima para que un grupo de nodos y de terminales inter- 
conectados puedan hacer pasar informacion de un punto a otro. 



El problema de las redes en modo datagrama radica en la dificul- 
tad de garantizar la entrega correcta y completa de la informacion, 
puesto que los diferentes paquetes que forman la transmision no 
mantienen un vinculo conocido por la red. Los paquetes pueden 
llegar fuera de orden, duplicados, o incluso se pueden perder sin 
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que la red pueda hacer gran cosa al respecto. Se deja al terminal 
receptor la responsabilidad de restaurar los posibles danos que 
haya tenido el paquete durante la transmision. 



• Redes que funcionan en modocircuito virtual. Estas redes pueden 
garantizar que la entrega de los paquetes sea correcta y comple- 
ta, y lo hacen aportando el concepto de conexion propio de las 
redes de conmutacion de circuitos. Es el circuito virtual. Este ultimo 
permite agrupar los paquetes relacionados de manera que el re- 
ceptor los recibe correctamente sin problemas de orden, duplica- 
cion o perdida. 

La asignacion de direcciones es uno de los conceptos basicos del nivel 
de red. Le permite, como sistema distribuido pero unico, decidir cual de 
los multiples terminales es el destinatario final de cada paquete. 

El direccionamiento constituye el procedimiento que permite a este 
sistema distribuido conducir la informacion por los diferentes nodos 
de origen a destino, minimizando el trayecto y el tiempo de transito, 
optimizando recursos, etc. 



2.4.4. Nivel de transporte 

El nivel de transporte permite una conexion fiable sobre cualquier 
tipo de red (fiable o no). En las redes de conmutacion de paquetes 
en modo datagrama es donde este nivel revela su importancia, pues- 
to que es el responsable de controlar las posibles deficiencies de las 
transmisiones. 

La funcion principal de este nivel consiste en asegurar la calidad de 
transmision entre los terminales que utilizan la red, lo que implica re- 
cuperar errores, ordenar correctamente la informacion, ajustar la ve- 
locidad de transmision de la informacion (control de f I u jo), etc. 



2.4.5. Niveles de sesion, presentacion y aplicacion 

Estos tres niveles se suelen explicar de manera conjunta, puesto que 
existen pocos ejemplos practicos de protocolos de sesion y de pre- 
sentacion. Ademas, la arquitectura Internet delega todos los trabajos 
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por encima de transporte a la aplicacion. No obstante, en el modelo 
OSI estan definidos comotres niveles diferentes e independientes, con 
atribuciones propias. 

El nivel de sesion es, en teoria, el encargado de gestionar las co- 
nexiones de largo duracion, la recuperacion de caidas de red de ma- 
nera transparente y los protocolos de sincronfa entre aplicaciones. 

El nivel de presentacion se encarga de conseguir que las diferentes 
plataformas (sistemas operatives, procesadores, etc.) se puedan en- 
tender al conectarse por medio de una misma red. Dicho de otra 
manera, soluciona el problema de la hetereogeneidad definiendo 
una manera universal de codificar la informacion. Dicha codificacion 
puede tener propiedades de eficiencia (por medio de la compresion, 
por ejemplo), propiedades de confidencialidad (por medio de la crip- 
tografia), etc. 

En el nivel de aplicacion residen los programas. En este nivel pode- 
mos encontrar servidores, clientes que acceden a estos ultimos, apli- 
caciones quetrabajan segun un modelo simetrico ( peer-to-peer ), etc. 



Actividad 

Asignad los diferentes niveles de las redes que cono- 
ceis a las funciones explicadas en este apartado. 
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II. Redes de area local 



3. Las redes de area local 



Una red de area local es un sistema que permite la interconexion de 
ordenadores que estan proximos ffsicamente. Entendemos por proxi- 
mo todo lo que no sea cruzar una via publica: una habitacion, un 
edificio, un campus universitario, etc. 



En el momento en que una red debe cruzar una calle, o una via publica 
en general, es preciso que una companfa de telecomunicaciones esta- 
blezca la comunicacion, puesto que son las unicas autorizadas para pa- 
sar llneas por zonas publicas. 



Una definicion mas precisa de red de area local, prescin- 
de de la distancia entre las estaciones y especifica que su 
caracter distintivo reside en que los mecanismos de enlace 
entre estaciones deben estar completamente bajo el con- 
trol de la persona o entidad que establece dicha red. 



Como comentabamos en la primera unidad, el objetivo que se perse- 
guia cuando se propusieron las primeras redes de area local era com- 
partir recursos entre diferentes ordenadores proximos (un sistema de 
almacenamiento masivo, una impresora o un dispositivo de conexion 
hacia el exterior, por ejemplo). Para este tipo de comunicaciones se pro- 
puso una filosoffa de diseno basada en la difusion de tramas con medio 
compartido, de manera que cuando una estacion pone una trama en el 
medio, el resto de estaciones puedan recibirla. Los receptores reales de 
la trama se la quedan y el resto, la ignora. 



Nota 

Las primeras redes de area local solo permitfan que uno de 
los ordenadores de la red (el servidor) ofreciera recursos al 
resto, que solo podfan actuar como clientes de este servi- 
dor, sin capacidad de ofrecer nada. De un tiempo a esta par- 
te, el software de red que elaboran empresas como Novell, 
Microsoft o Apple permite que todas las estaciones puedan 
actuar como servidores y clientes al mismo tiempo. 
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Ultimamente y como veremos mas adelante, se han aplicado tecnicas 
de conmutacion a las redes de area local, para conseguir mejorar su 
rendimiento. 

Otra mejora importante ha sido la aparicion de las redes de area local 
inalambricas ( wireless LAN), en las que el enlace entre estaciones no se 
lleva a cabo por medio de cables, sino por medio de enlaces radioelec- 
tricos. Las ventajas de este tipo de enlaces, en cuanto a movilidad y fa- 
cilidad de instalacion, son evidentes. 

En una red es imprescindible identificar los ordenadores que forman 
parte de la misma. Cuando un ordenador genera una trama para otro, 
ademas de los datos que le quiere enviar, le pone el identificador del 
ordenador (u ordenadores) destino y el suyo, para que quien reciba la 
trama pueda saber quien se la ha enviado. 

Para construir una red local, se precisan basicamente dos cosas: 
hardware (tarjetas, cables, conectores) y un sofware que sea consciente 
de que existen diferentes maquinas conectadas y ofrezca los servicios ne- 
cesarios para que las aplicaciones puedan aprovecharlo. Lo mas logico 
es que este software se integre en el sistema operativo y ofrezca a las apli- 
caciones la vision de la red como un recurso propio mas. Estos recursos 
de hardware y software necesarios pueden seranalizados desdeel punto 
de vista de la torre OSI, como se explicaba en la unidad anterior: 



Figura 14. 



Nota 



Como se puede ver en la figura anterior, los niveles necesarios para im- 
plementor una red de area local son los dos inferiores (ffsico y enlace) y 
el superior (aplicacion). A nivel de usuario no somos conscientes de esta 
subdivision porque, como hemos dicho, el codigo que implementa los 
servicios asociados a los niveles esta integrado en el sistema operativo 
de las estaciones. 



Los niveles red, transporte, 
sesion y presentation tienen 
sentido en redes de area ex- 
tensa, como veremos en las 
unidades siguientes. 
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El nivel fisico corresponde al hardware: a la tarjeta de red, a las senales 
electromagneticas que viajan por el medio de transmision, a los dispo- 
sitivos que generan estas senales a partir de bits, etc. 

El nivel de enlace, como ya sabemos, proporciona fiabilidad en el 
intercambio de tramas entre las estaciones: basicamente control de 
errores y control de flujo. Pero, por el hecho de usar un medio com- 
partido, sera necesario establecer mecanismos para que todas las 
estaciones puedan usarlo cuando lo precisen, pero sin molestarse. 
Si dos estaciones ponen tramas en el medio de transmision de for- 
ma simultanea, estas se mezclaran de manera que se convertiran 
en algo ininteligible. Esta situacion se conoce como colision de tra- 
mas y necesitamos mecanismos para controlar el acceso al medio 
compartido de manera que no se produzcan, o que si se producen, 
la red pueda recuperarse y seguir funcionando. 

La inclusion de estos mecanismos en la torre OSI se podia llevar a cabo 
anadiendo un nivel mas a la torre o, como al final sucedio, incluyendo- 
los en el nivel de enlace. Asi, en contextos de area local, el nivel de en- 
lace incluye dos subniveles: 

• MAC ( medium access control o control de acceso al medio), que 
se encarga propiamente de la politico de acceso al medio 

• LLC ( logical link control o control del enlace logico), que se en- 
carga de los servicios tipicos de enlace: control de errores y 
control de flujo. 
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4. Topologias de las LAN 



Lo primero que caracteriza una red local es la manera en que se 
conectan las estaciones; es decir, la forma que adopta el medio 
compartido entre las mismas. Basicamente existen tres topologias 
posibles: 

• Topologia en estrella. 

• Topologia en bus. 

• Topologia en an il lo. 



4.1 . Topologia en estrella 



La topologia en estrella consiste en conectar cada ordenador a un 
punto central, que puede ser tan sencillo como una simple union fi- 
sica de los cables. 

Cuando un ordenador pone una trama en la red, esta aparece de 
inmediato en las entradas del resto de ordenadores. 




Aunque se han definido estandares para este tipo de redes, en la ac- 
tualidad ya casi no existen, puesto que no aportan ninguna ventaja 
sobre el resto y si muchos inconvenientes. 
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4.2. Topologia en bus 

La topologia en bus consiste en un cable al que se unen todas las es- 
taciones de la red. 




Todos los ordenadores estan pendientes de si hay actividad en el ca- 
ble. En el momento en que un ordenador pone una trama, todos los 
ordenadores la cogen y miran si son el destinatario de la misma. Si 
es asf, se la quedan, en caso contrario, la descartan. 

Las primeras redes en bus utilizaban un cable coaxial grueso, co- 
nectores tipo BNC, y los ordenadors se conectaban al mismo con 
un dispositivo denominado transceptor (transceiver), que era exte- 
rior. Con posterioridad, aparecio una nueva version, con un cable 
mas fino ( thin-ethernei) y con unos transceptores mas pequenos, 
de manera que se podian integrar en el adaptador de red y asf no 
se veian. 



Nota 

Los caprichos de la electronica exigen que el cable 
este "tapado" en los dos extremos, para que los bits no 
se "pierdan". Elio se lleva a cabo con una resistencia 
de cargo. 

Cuando un ordenador pone una trama en el cable, esta 
recorre el cable por completo en los dos sentidos hasta 
los extremos, donde es absorbida por los tapones. 
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4.3. Topologia en anillo 



La topologia en anillo consiste en conectar coda ordenador a dos 
mas, de manera que se forme un anillo. Cuando un ordenador 
quiere enviar una trama a otro, esta debe pasar por todos los or- 
denadors que haya entre ellos: la circulacion por el anillo es uni- 
direccional. 




El dispositivo que conecta el ordenador al anillo es el repetidor, un 
circuito con tres conexiones: 



Figura 1 9. 




• Conexion de entrada de tramas desde el anillo al ordenador (A). 

• Conexion de salida de tramas desde el ordenador al anillo (B). 
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• Conexion bidireccional, por la que pasan todas las tramas que 
entran y salen del ordenador (C). 

El repetidor tiene tres modos de trabajo: 

• Modo escucha: el repetidor toma las tramas que le llegan por A y 
las pone simultaneamente en B y C, para que continuen por el 
anillo y para que el ordenador reciba una copia de las mismas y 
la analice. Si es el destinatario de la trama, se la queda y, en caso 
contrario, la descarta. 

• Modo transmision: el ordenador envfa informacion a la red. Pone 
una trama en C, de manera que cruza el repetidor y sale por B 
hacia el ordenador siguiente del anillo. 

• Modo cortocircuito: las tramas que llegan por A se ponen directa- 
mente en B sin proporcionar una copia de las mismas al ordena- 
dor. Este modo sirve para que el anillo continue funcionando si el 
ordenador correspondiente no esta activo. 



4.4. Pseudotopologia de las redes inaiambricas 



Hablar de topologfa en una red inalambrica parece fuera de lugar, 
porque no 'vemos' ningun medio de transmision. Pero en realidad el 
"eter" por donde viajan las ondas se considera un medio de transmi- 
sion, y si lo comparamos con las tres topologfas descritas, vemos que 
se puede comparar a la topologfa en bus. 



Not a 

De hecho, las ondas electromagneticas no necesitan 
ningun soporte ffsico para ser transmitidas. Se propa- 
gan en el vacfo. Pero hasta que esto no fue demostra- 
do, los cientfficos utilizaban el termino "eter" para 
designar algo que se imaginaban que tenfa que existir 
pero eran incapaces de ver. 



En un anillo o en una estrella en realidad existen 'n' medios indepen- 
dientes que conectan una estacion a otra (o al punto central), mien- 
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tras que en un bus tenemos un solo medio (un cable) al que se 
conectan todas las estaciones, de la misma manera que en una red 
inalambrica tenemos un solo medio (el aire) donde las estaciones 
ponen sus tramas. 




La topologfa, como veremos mas adelante, condiciona los mecanis- 
mos de acceso al medio que se pueden usar en una red local. En el 
caso de las redes inalambricas esto es particularmente determinante. 
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5. Cableado estructurado 



Las topologias en bus y en anillo comportan un serio problema de 
cableado a la hora de implementarlas. Aunque es relativamente 
sencillo montar una red en bus o en anillo, es muy complicado 
mantenerla y ampliarla: cuando fa 1 1 a un cable o una conexion, la 
red entera deja de funcionar, y no es sencillo localizar el punto 
exacto donde se encuentra el fallo. Es preciso comprobar la red 
entera, lo que en numerosas ocasiones es complicado, puesto que 
los cables pueden pasar por falsos techos o conducciones de dificil 
acceso. 

Este problema ha hecho pensar en un nuevo diseno de red mas con- 
trolable: el cableado estructurado. 

El cableado estructurado consiste en hacer una preinstalacion de red 
similar a la de las redes telefonicas. A cada punto de trabajo se ha- 
cen llegar dos Ifneas: una para el telefono y otra para los datos. To- 
dos los cables llegan a una habitacion, donde se establecen las 
conexiones: los cables de telefono se direccionan hacia la centralita 
y los de los datos, hacia un dispositivo que permite la interconexion 
en red local. 



En 1 991 se publico el EIA/TIA 568 sobre cableado de telecomunica- 
ciones para edificios comerciales. El proposito de dicho estandar es: 



• Ser universal, tanto en servicios soportados como en fabricantes 
compatibles. 



Nota 



EIA/TIA: 

Electronic Industries Association 
/Telecommunication Industry 
Association. 



• Ser base para el desarrollo de ottros estandares de comunicacio- 
nes (voz, imagen, LAN, WAN). 



• Definir parametros que permitan definir y establecer el cablea- 
do del edificio incluso antes que nadie lo ocupe. Se concibe el 
cableado como un servicio mas del edificio (luz, agua, gas... y 
datos). 
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El estandar especifica las senales a usar, asf como los aspectos me- 
canicos de los cables, los conectores, los armarios, etc. 



Por norma general, se realiza un cableado a dos niveles: 

• Cableado horizontal: en cada planta (si es preciso cablear varias) 
se ponen cables desde un armario hasta los puntos terminales. 

• Cableado vertical: desde cada armario de planta se ponen ca- 
bles hasta una habitacion del edificio donde se encuentran los 
dispositivos de red, los direccionadores ( routers ) hacia el exterior, 
la centralita telefonica, etc. 



Nota 



Hablando con propiedad 
diremos que una red tiene 
topologfa ffsica en estrella y 
topologfa logica en bus. 



En cada planta necesitamos crear una red local en el punto donde 
confluyen los cables que provienen de cada una de las estaciones. 
Parece que una topologfa en estrella serfa la mas adecuada, pero 
como hemos comentado, tal como se habfa concebido, era la que 
ofrecfa menos prestaciones. La solucion es combinar las ventajas de 
la topologfa ffsica en estrella con el funcionamiento de los buses o 
los anillos. O sea, usar para interconectar las estaciones un disposi- 
tivo, alojado en el armario de planta, que se comporte como un bus 
o como un anillo. En el caso del bus (la topologfa mas utilizada ac- 
tualmente), este dispositivo se conoce como concentrador o, en in- 
gles, hub. 



Lectura complementaria 



Una buena aproximacion al 
funcionamiento de los con- 
centradores y los conmuta- 
dores la encontrareis en: 
A.S. Tanenbaum (2003). 
Redes de computadores. 
Mejico: Pearson Educacion. 



Una topologfa asf, donde el elemento central es un dispositivo ac- 
tivo que esta simulando un dispositivo pasivo, llevo al desarrollo de 
las LAN conmutadas. El razonamiento es el siguiente: cuando el 
hub recibe una trama, para comportarse como un bus tiene que re- 
enviarla hacia el resto de estaciones. Pero, el hub tiene capacidad 
de proceso: puede analizar la trama y, en particular, puede averi- 
guar cual es su destinatario. Entonces, si el hub conoce los identifi- 
cadores de las diferentes estaciones que tiene conectadas, puede 
enviar la trama unicamente a su destinatario, y asf disminuir el nu- 
mero de tramas en la red, y, por tanto, aumentar la eficiencia. Los 
dispositivos que se comportan asf se denominan conmutadores (en 
ingles, switch). 
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Por lo que se refiere al medio ffsico, se usan tanto pares de cobre 
trenzados como fibra optica, aunque en mucha mayor medida los 





primeros por su menor coste para similares prestaciones. Se han es- 
pecificado categorfas de cables, cada cual con unas capacidades y 
unos requisitos mfnimos a cumplir. Hoy en dfa el mas usado es el ca- 
ble categorfa 5e, que pemite un ancho de banda de 1 00 MHz, el re- 
querido para las LAN de alta velocidad, como Fast Ethernet y Gigabit 
Ethernet. 



Los costes de instalacion de un sistema de cableado es- 
tructurado son muy altos; pero su mantenimiento es 
muy simple y barato. 



Nota 



Hablaremos de FastEthernet 
y Gigabit Ethernet en el 
apartado siguiente. 



Si falla un cable, solo fa I la una estacion de trabajo, no toda la red, 
y, si falla toda la red, es que se ha estropeado el concentrador. Tanto 
un caso como el otro son muy rapidos de solucionar. 



Actividad 

Los que tengais acceso a una instalacion con cableado 
estructurado, estudiadla: observad las conexiones, los 
cables, los armarios de planta, los conmutadores, etc. 
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6. Control de acceso al medio 



Dado que cualquier ordenador de la red puede poner tramas al me- 
dio compartido, es preciso establecer mecanismos de control que re- 
gulen este acceso de manera eficiente, justa y fiable. 



El control de acceso al medio (MAC) es un mecanismo 
que decide que estacion tiene acceso al medio de 
transmision para emitir una trama de informacion. 



En general, los protocolos de acceso al medio se pueden clasificar 
en tres grandes grupos: 

• Control de acceso al medio estatico 

• Control de acceso al medio dinamico (centralizado o distribuido) 

• Control de acceso al medio aleatorio 

Coda uno de estos tipos de accesos tiene ventajas e inconvenientes, y 
se apli-can a redes muy diferentes. De hecho, las politicos de acceso 
al medio estan muy vinculadas a la topologfa utilizada. De este modo, 
en una topologfa en anillo, la manera mas natural de controlar el ac- 
ceso es porpaso de testigo ( token passing ), que es un ejemplo de con- 
trol dinamico distribuido. En la topologfa en bus, tambien se puede 
utilizar este sistema; sin embargo, esta mucho mas generalizado el uso 
de la tecnica CSMA/CD, que es de tipo aleatorio. En las redes inalam- 
bricas se usa una politico de acceso al medio que es una combinacion 
de control estatico y aleatorio. 

En esta unidad vamos a describir las dos politicos mas comunes 
hoy en dfa en las redes cableadas: el paso de testigo y CSMA/CD. 



6.1 . Paso de testigo 

Como decfamos, la politico de paso de testigo es la mas apropiada 
para las redes en anillo. Asf pues, para describir su funcionamiento 
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Lectura complementaria 



Podeis encontrar la defini- 
cion de todos los tipos de 
control de acceso al medio 
en: 

A.S. Tanenbaum (2003). 
Redes de computadores. 
Mejico: Pearson Educacion. 



Nota 



CSMA es la sigla de Carrier 
Sense Multiple Access (acce- 
so multiple por deteccion de 
portadora) y CD es la sigla 
de Collision Detection (de- 
teccion de colisiones). 






asumiremos que estamos en una red de esta topologla. En ingles es- 
tas redes se denominan token-passing ring, literalmente "anillo con 
paso de testigo". 

El funcionamiento de la politico de paso de testigo es el siguiente: 

Se define una trama especial, el testigo. Cuando una estacion lo 
recibe, tiene permiso para poner una trama propia en la red. Una 
vez esta trama ha dado toda la vuelta, y despues de que sus des- 
tinatarios se hayan quedado una copia de la misma, la estacion 
que la ha puesto la quita y libera el testigo que llegara a la esta- 
cion siguiente del anillo. Esta estacion repite el procedimiento: 
saca el testigo de la red y pone una trama suya o, si no tiene nada 
para enviar, pasa el testigo a la estacion siguiente. Las estaciones 
que tengan informacion para transmitir deben esperar a tener el 
testigo para ponerla en la red. 

Este mecanismo de control del medio permite con la misma faci- 
lidad la emision de tramas tanto a una sola estacion como a muchas. 
La trama recorre todo el anillo, por tanto todos los repetidores la 
ven pasar. Cada uno comprueba si en el campo "destinatario" de 
la cabecera de la trama aparece su identificador. En caso afirma- 
tivo, se queda una copia y la retransmite hacia la siguiente esta- 
cion. En caso contrario la retransmite sin quedarse copia. 



Nota 



IEEE es la sigla del Institut of 
Electric and Electronic Engi- 
neers (Instituto de ingenie- 
ros electricos y electronicos). 



Las velocidades de trabajo de las redes en anillo con testigo estan 
normalizadas: 4, 16 y 100 Mbps. Si se utiliza fibra optica como me- 
dio de transmision, la red, que se denomina FDDI (fiber distributed 
data interface), puede superar los 100 Mbps. 

Las redes de paso de testigo fueron inventadas por IBM. Con poste- 
rioridad, el IEEE elaboro el estandar 802.5, que recogia toda la in- 
formacion existente sobre las mismas. 



6.2. CSMA/CD 

Como ya hemos comentado, CSMA/CD es una politico de acceso al 
medio de tipo aleatorio, lo cual quiere decir basicamente que las es- 
taciones no acceden al medio de una forma prefijada sino cuando 
quieren. De esta forma se consigue aumentar la eficiencia de la red 



66 




con respecto a los sistemas de control estaticos. Obviamente hara falta 
controlar el caso en que dos estaciones quieran transmitir a la vez. 



Nota 

Los mecanismos de control del tipo estatico se basan 
en repartir el acceso al medio entre las estaciones de 
forma fija. Si cuando a una estacion le toca acceder al 
medio no tiene nada que transmitir, el lapso de tiempo 
asignado no puede ser aprovechado por otra y el me- 
dio queda desocupado. 

De politicos de acceso al medio de tipo aleatorio hay varias, pero las 
"comercialmente utiles" son dos, CSMA/CD y CSMA/CA. La primera es 
la mas indicada para redes con topologia en bus (ya sea con un bus 
real, cableado, como con un hub, en un entorno de cableado estructu- 
rado). La segunda es la que se usa en las redes inalambricas Wi-Fi, que 
como hemos comentado, tienen una topologia asimilable a un bus. 

Veamos en primer lugar como funciona CSMA, para luego describir 
la funcionalidad adicional de la deteccion de colisiones (CD). 

La politico de acceso CSMA (acceso multiple por deteccion de porta- 
dora) funciona de la manera siguiente: 

Los ordenadores escuchan constantemente el medio (miran si hay por- 
tadora). Cuando tienen una trama para transmitir, si detectan que no 
hay actividad en el medio, la ponen y, en caso contrario, esperan y si- 
guen escuchando hasta que el medio queda libre, entonces transmi- 
ten su trama. Si no tienen nada para transmitir, cuando detectan una 
trama en el medio, la toman y la procesan. 

Este algoritmo presenta un inconveniente claro: existe la posibili- 
dad de que dos estaciones quieran enviar una trama en el mismo 
momento. Ambas escuchan el medio, no detectan actividad y emiten 
simultaneamente. Entonces se produce una colision: las senales 
electromagneticas se mezclan y el resultado es algo ininteligible. 
El control de errores que se efectua en el subnivel LLC sera el en- 
cargado de detector dicha circunstancia y solicitor la retransmi- 
sion de las tramas que se han corrompido. 



Podemos mejorar la politico CSMA anadiendole un procedimiento 
adicional: cuando una estacion ya ha empezado a transmitir, si- 
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gue escuchando el medio para detector si se produce una colision, en 
cuyo caso deja de transmitir inmediatamente, para reducir asi el tiem- 
po de colision, y espera un tiempo aleatorio (es una manera de evitar 
una nueva colision) para volvera empezarel proceso. Esta variante re- 
cibe el nombre de CSMA/CD, por la deteccion de las colisiones. 

Este modo de trabajo marca la existencia de un parametro muy impor- 
tante en las redes CSMA/CD, que es la longitud minima de trama. 

Una trama en una red local CSMA/CD ha de ser suficientemente larga 
para que una colision sea detectada antes de que finalice su transmi- 
sion. Esta longitud minima de trama es funcion unicamente de la ve- 
locidad de transmision de las senales en el medio. Este parametro, a 
su vez, marca otro, tambien muy importante en el diseno de redes, 
como es el diametro de la red, o distancia entre las estaciones mas 
alejadas. 

La red Ethernet es una topologia en bus que utiliza la politico de acceso 
al medio CSMA/CD y fija como longitud minima de trama 512 bits. La 
invento Xerox, junto con Intel y Digital, y el IEEE la elevo a la categoria 
de estandar: IEEE-802.3. 

La red Ethernet trabaja a 10 Mbps. Con posterioridad, aparecio la 
FastEthernet, que trabaja a 100 Mbps, y, mas tarde, la Gigabit 
Ethernet que, como su nombre indica, trabaja a 1 Gbps. 



Actividad 

Que una red vaya a 1 0 Mbps no quiere decir que todas 
las conexiones se realicen a esta velocidad. Si teneis ac- 
ceso a una red de area local, por un lado, averiguad a 
que velocidad funciona y por otro, haced una transfe- 
rencia de informacion entre dos estaciones y medid la 
velocidad real a la que se ha realizado (el cociente entre 
el numero de bytes transmitidos, multiplicado por ocho, 
y dividido por el tiempo que ha durado la transmision, 
en segundos). Cuanto mas grande sea el fichero que 
transmitais, mejor. Podeis hacer la prueba bajo diferen- 
tes condiciones de trabajo, como por ejemplo con pocas 
estaciones activas, con muchas transmisiones simulta- 
neas, etc. Comparad los valores obtenidos con la velo- 
cidad nominal de la red. 
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III. TCP/IP 



7. Estructura de protocolos en Internet 



El modelo Internet giro en torno a los protocolos TCP/IP. IP es un pro- 
tocolo que proporciona mecanismos de interconexion entre redes de 
area local y TCP proporciona mecanismos de control de flujo y erro- 
res entre los extremos de la comunicacion. 



No se trata de una arquitectura de niveles formal como la torre OSI, 
que ya hemos visto en la unidad 1 . De hecho, podrfamos considerar 
que el modelo de la red Internet consta solo de cuatro partes o nive- 
les; es decir, todo lo que hay por debajo del IP, el IP, el TCP y todo 
lo que hay por encima del TCP: 



1) Por debajo de IP. A este nivel, en el entorno Internet, se le llama 
nivel de red local o, simplemente, nivel de red. Por norma general, 
esta formado por una red LAN, o WAN (de conexion punto a pun- 
to) homogenea. Todos los equipos conectados a Internet imple- 
mentan dicho nivel. 

2) Nivel IP o nivel Internet (nivel de Internetworking). Este nivel 
confiere unidad a todos los miembros de la red y, por consi- 
guiente, es el que permite que todos se puedan interconectar, 
con independencia de si se conectan a la misma por medio de 
llnea telefonica, ISDN o una LAN Ethernet. El direccionamiento 
y la asignacion de direcciones constituyen sus principales fun- 
ciones. Todos los equipos conectados a Internet implementan 
este nivel. 

3) Nivel TCP o nivel de transporte. Este nivel confiere fiabilidad a 
la red. El control de flujo y de errores se Neva a cabo principal- 
mente dentro de este nivel, que solo es implementado por los 
equipos usuarios de la red Internet o por los terminales de Inter- 
net. Los equipos de conmutacion (direccionadores o routers ) no lo 
necesitan. 
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4) Por encima de TCP. Nivel de aplicacion: Este nivel corresponde 
a las aplicaciones que utilizan Internet: clientes y servidores de 
WWW, correo electronico, FTP, etc. Por el lo se le denomina nivel 
de aplicacion. Solo es implementado por los equipos usuarios de 
la red Internet o los terminales de Internet. Los equipos de conmu- 
tacion no lo utilizan. 



Figura 21 . 



Modelo Internet 

Nivel de aplicacion 

Nivel de transpose 

Nivel de Internet 

Nivel de red 






Es importante destacar que solo los equipos terminales implementan 
todos los niveles; los equipos intermedios unicamente implementan 
el nivel de red y el nivel IP. 



Figura 22. 
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Internet se situa "encima" de las redes locales ya existentes. No 
redefine el concepto ni propone protocolos de red local nuevos. 













7.1 . Protocolos de Internet 



En los niveles intermedios existen otros protocolos complementarios, 
ademas de TCP e IP. La figura siguiente seria un mapa bastante com- 
pleto de los protocolos que se usa en Internet: 





Figura 23. 


Nivel 


Protocolos 




Como ya hemos comentado, el concepto nivel no existe en Internet. 
Este concepto se utiliza en otros modelos de red, como la OSI. No 
obstante, como es un concepto util, lo utilizaremos para plantear el 
estudio de los diferentes protocolos de la manera siguiente: 



a) En primer lugar, describiremos el IP y los protocolos que colabo- 
ran con el: ARP e ICMP. 

b) Despues, estudiaremos ciertos aspectos basicos del nivel de red 
para las diferentes posibilidades de conexion a Internet actuales: 
las LAN Ethernet y los accesos por linea punto a punto con el pro- 
tocolo PPP o con ADSL. 



Dejaremos para unidades posteriores el estudio del nivel de trans- 
porte y del nivel de aplicacion. 
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7.2. Encapsulamiento 

En cualquier arquitecturade niveles (sea mas o menos formal) en que 
exista una comunicacion vertical dentro de cada maquina, los datos 
que se generan en el nivel superior (aplicacion) atraviesan el resto de 
niveles para "salir" de la maquina por el nivel ffsico. 

Cada uno de estos protocolos funciona con unas estructuras fundamen- 
tales que genericamente se conocen como PDU (protocol data units). Sin 
embargo, en cada nivel se utilizan nombres diferentes para denominar 
lo que, de hecho, tiene funciones equivalentes. En el conjunto de proto- 
colos Internet tenemos las siguientes PDU: 

• Las PDU Ethernet o PPP se denominan tramas. 

• Las PDU del nivel de interconexion (IP o ARP) se suelen denominar 
paquetes, aunque las PDU ICMP se suelen denominar mensajes, se- 
guramente porque viajan en paquetes IP. 

• En el nivel de transporte, se habla de segmentos en TCP, y de da- 
tagramas en UDP. 

• En niveles superiores que utilizan UDP, por norma general se utiliza 
la palabra PDU (SNMP-PDU, por ejemplo). En el caso del TCP, el ser- 
vicio que proporciona a las aplicaciones es el flujo de bytes sin es- 
tructura foyte stream ). Por tanto, el concepto PDU deja de tener 
sentido en el nivel superior a TCP. 

El resultado de los diferentes encapsulamientos en cada nivel es 
que, cuando el nivel superior decide transmitir cierta informacion, 
se provoca una cascada de PDU que va descendiendo hasta el nivel 
inferior, que finalmente es el que transmite ffsicamente los bits que 
resultan del mismo. 



Nota 

Para calcular la longitud de trama necesaria para 
transmitir un byte de informacion, veremos, a modo 
de ejemplo, la emulacion de terminal que efectua el 
programa telnet y el protocolo que Neva el mismo 
nombre. 
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Imaginemos que pulsamos una tecla sobre la ventana 
del programa telnet. Esta accion llega en forma de 
un byte unico al nivel TCP, que encapsula dicho byte 
en un segmento TCP. Este segmento tendra una ca- 
becera de 20 bytes y un contenido que sera el byte co- 
rrespondiente a la tecla pulsada. Estos 21 bytes se 
transportaran dentro de un paquete IP que, general- 
mente, formara un paquete con 20 bytes de cabecera 
mas el contenido ya mencionado de 21 bytes. Este 
paquete de 41 bytes ira, a su vez, dentro de una tra- 
ma que lo transportara por su soporte ffsico de trans- 
mision. Si el soporte de transmision es una Ifnea 
telefonica con un modem y utilizamos PPP, el resulta- 
do puede ser que le anadamos 8 bytes mas. 

De todo el lo resulta una trama de 49 bytes (8 + 20 + 
+ 20 + 1) de longitud para transmitir uno solo. La fi- 
gura siguiente muestra esta estructura: 



Figura 24. 



Pirdmide PDU 



1 byte 
Daios I 



20 bytes 1 byte 
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8. El IP (Internet protocol) 



IP y TCP son un par de protocolos bien compenetrados. El 
IP es un protocolo de interconexion de red orientado a da- 
tagrama. Por tanto, no dispone del concepto de circuito 
virtual, de manera que no es capaz de recuperar tramas 
perdidas, ni de garantizar que las tramas se entregaran 
en el orden correcto -puesto que los paquetes pueden se- 
guir caminos diferentes y, por tanto, sufrir retardos dife- 
rentes-, ni que el ritmo de recepcion sea el adecuado 
para que el receptor procese convenientemente los datos. 



El IP es del tipo best effort (podriamos traducirlo como 'con la mejor in- 
tendin', o 'quien hace lo que puede no esta obligado a mas'). 
Evidentemente, cuando utilizamos una red, no siempre podemos 
conformarnos con conseguir que la informacion llegue si la red puede. 
Aquf interviene el TCP, que es responsable de conseguir que la informa- 
cion llegue en las condiciones de fiabilidad deseadas. 



Not a 

Hay detractores acerrimos, asf como defensores incondi- 
cionales de la filosoffa best effort, aplicada a las redes y, 
seguramente, ambos grupostienen una parte de razon. La 
red X.25 es un ejemplo casi opuesto a esta filosoffa que 
proporciona a sus usuarios unos niveles de fiabilidad y fle- 
xibilidad razonablemente elevados, gracias a la utilizacion 
de la conmutacion de paquetes con circuitos virtuales. 

De hecho, la historia da la razon a los defensores de la 
filosoffa best effort, puesto que el X.25 actualmente se 
considera una tecnologfa casi obsoleta, mientras que el 
IP esta de moda. Las razones deben buscarse, como 
siempre, en el coste. La filosoffa IP permite implementor 
redes con un coste mfnimo: pensad que el TCP solo pre- 
cisa implementarse en los terminales de la red, y no enlos 
nodos de conmutacion. Por tanto, los nodos de conmu- 
tacion IP son mucho mas simples que los de X.25. 



Lectura complementaria 



Una buena descripcion de 
los algoritmos de direccio- 
namiento usado en Internet 
se puede encontrar en: 

W.R. Stevens (1994). TCP/IP 
Illustrated. Vol. 1 The protocols. 
Wilmintong: Addison-Wesley. 
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8.1 . Direcciones IP 



Las direcciones IP son unicas para cada maquina. Para ser preci- 
sos, cada direccion es unica para cada una de las interfaces de red 
IP de cada maquina. Si una maquina dispone de mas de una interfaz 
de red, necesitara una direccion IP para cada una. 

Las direcciones IPtienen una longitud de 32 bits (4 bytes). 



Nota 



El unico objetivo de esta no- 
tacion es la legibilidad hu- 
mana. No se puede perder 
nunca de vista que una di- 
reccion IP son 32 bits. 



Para representor una direccion, se suele escribir los 4 bytes en deci- 
mal y separados por puntos. Por ejemplo: 



212.45.10.89 



La numeracion en IP sigue una filosoffa jerarquica. Cada direccion esta 
formada por dos partes. Una corresponde a la red donde esta la esta- 
cion y la otra, a la propia estacion. 



Para conseguir que no haya ninguna direccion igual, Internet dis- 
pone de una organizacion denominada Internet Network Information 
Center o InterNIC que se dedica a esta tarea. En la actualidad, esta 
entidad delega la responsabilidad de la asignacion de direcciones 
a entidades regionales. Las direcciones se asignan por grupos o re- 
des, no individualmente. 



Los tipos de redes que tienen cabida en Internet se distinguen por la can- 
tidad de estaciones que pueden soportar, y son los siguientes: 

1) Las redes de close A reservan el primer byte como identificador 
de red y los tres restantes como identificadores de estacion. El pri- 
mer bit del primer byte vale 0, por tanto, en Internet solo puede 
haber 128 redes de close A (con 2 24 estaciones cada una como 
maximo). Hace mucho tiempo que ya no queda ninguna para 
asignar. 

2) Las redes de close B tienen 1 6 bits para cada campo; los dos pri- 
meros bytes del identificador de red valen 1 0, por tanto, hay 
1 6.384 (2 1 4 ) redes de, como mucho, 65.536 estaciones. De close 
B no queda ninguna para asignar. 
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3) Las redes de clase C reservan 24 bits para el identificador de red 
(con los tres primeros bits 1 1 0) y los 8 restantes son para el iden- 
tificador de estacion. 

Una vez que se conoce una direccion, es facil saber si corresponde a 
una red de clase A, B o C, como se puede ver en la figura siguiente: 




La clase A esta pensada para grandes empresas o corporaciones, 
con muchos terminales por identif icar; la clase B, para corpora- 
ciones medianas; la clase C, para entornos mucho mas peque- 
nos; la clase D esta destinada al trafico multicast IP, y la clase E, 
de momento, no tienen ningun uso concreto. La direccion comen- 
tada con anterioridad (212.45.10.89) es de clase C. 



Not a 

Classless Inter-Domain Routing (CIDR) 

El espacio de direcciones se esta agotando a marchas 
forzadas y, si bien existen tecnicas relacionadas con la se- 
guridad que ayudan a mitigar este problema (como el 
NAT, network address translation ) el hecho de utilizar el 
concepto de "clase" ha agravado el problema: algunas 
corporaciones que han reservado una red clase A o B y 
solo han aprovechado una pequena parte de la misma, 
han dejado sin un buen trozo del espacio de direcciones 
al resto de Internet. 
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Hoy dla, en lugar de proporcionar redes close C (de 
las otras ya no quedan) lo que se hace es dar grupos 
mayores (tecnicamente, se podrlan dar mas pequenas, 
pero no se hace) limitados por mascaras intermedias 
entre la close B y la C. Por ejemplo, si alguien quiere 
una red de un miliar de direcciones necesita cuatro re- 
des de close C. En lugar de proporcionarle estas cuatro 
redes independientes, se le da una mascara de 22 bits: 
quedan 1 0 para direcciones de terminal, lo que permi- 
te 1.024 terminales. 



8.1.1. Mascaras de red 

Cuando un administrador de sistemas recibe el encargo de ges- 
tionar un conjunto de direcciones, es posible que necesite confi- 
gurar internamente diferentes LAN con este conjunto. Por ello, el 
mecanismo para distinguir distintas redes (LAN) entre si no se puede ba- 
sar exclusivamente en los bits identificadores de close que hemos co- 
mentado con anterioridad. 

La mascara de red constituye el mecanismo que nos permitira 
conseguir mas flexibilidad. Por medio de una mascara de 32 bits, 
definiremos los bits que identifican la red (bits en 1 ) y los que iden- 
tifican la estacion (bits en 0). Por norma general, los bits 1 y los 0 
son consecutivos, pero no necesariamente. 

A continuacion, definimos de nuevo el concepto identificador de 
red, adaptandolo a la mascara: el identificador de red es la por- 
cion de direccion IP que encaja con los bits 1 de la mascara. 

El concepto mascara es capital para la comprension del funciona- 
miento de las redes IP, permite a una estacion decidir si el destino al 
que debe transmitir un paquete se encuentra dentro de la misma red 
de area local que este ultimo o si, por el contrario, se encuentra en 
una LAN remota y, por tanto, debe delegar su transmision a algun 
equipo de su misma LAN (el direccionador) para que se encargue de 
hacer llegar el paquete a su destino. 
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Todas las estaciones de una misma red de area local 
deben utilizar el mismo identificador de red y es preciso 
que todas las estaciones posean la misma mascara. 



Nota 

Si tenemos dos estaciones con las direcciones 
147.83.153.100 y 147.83.153.200, podemos deducir 
que estan interconectadas directamente (por una LAN) si 
la mascara de su red es 255.255.255.0, asi como dedu- 
cinamos que no estan conectadas con la misma LAN si la 
mascara fuese, porejemplo, 255.255.255.128. 



Nota 

Una notacion alternative es proporcionar el numero 
de bits 1 de la mascara. Asi pues, la mascara 
255.255.255.0 es una mascara de 24 bits y la 
255.255.255.128 es una mascara de 25 bits. 

En ocasiones, podemos ver una direccion con el anadido 
de la mascara; por ejemplo: 

147.83.153.100/24. 

Sin embargo, esta notacion solo es util para mascaras 
con 1 consecutivos. 



Cuando la mascara no coincide exactamente con la estructura de 
closes definida, entonces se habla de subnetting, porque estamos 
creando subredes dentro de una red. 



8.1.2. Direcciones de proposito especial 

Existen diferentes direcciones especiales. Nosotros expondremos a 
continuacion solo las mas importantes: 



Ejemplo 



La mascara 212.45.10.0/ 
27. Permite 6 subredes dis- 
tintas dentro de la red de 
close C 212.45.10.0. 



Direccion de red. Las direcciones de red se expresan con la di- 
reccion que tendria cualquier estacion suya y con todos los bits del 
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identificador de estacion a cero. Por ejemplo, la red en que se en- 
cuentra la estacion 1 47.83.1 53.1 00/24 es la 1 47.83.1 53.0/24 y 
la red en que se encuentra la estacion 147.83.153.200/25 es la 
147.83.153.128/25. 

• Direccion 0.0. 0.0. Esta direccion senala al mismo ordenador que 
la envfa. Tiene dos funciones basicas: 

- Aparecer como direccion origen en paquetes IP generados por esta- 
ciones sin direccion IP asignada. Normalmente solo aparece mien- 
tras la estacion intenta averiguar su direccion mediante protocolos 
como RARP (reverse address resolution protocol), BOOTP ( bootstrap 
protocol) o DHCP ( dynamic host configuration protocol ). 

- Servir al software de gestion de direccionamiento para indicar la 
ruta por defecto. 

• Direccion 127.0.0.1 (loopback). Esta direccion no es valida para 
los paquetes IP. El software de red la utiliza para transmitir paque- 
tes a la maquina local (de hecho, los paquetes no son enviados, 
sino que son entregados al destino por el mismo sistema operati- 
ve). En realidad, los tres bytes del identificador de estacion son 
irrelevantes. Esta direccion solo tiene interes para programar apli- 
caciones; los sistemas de red no veran nunca que ningun paquete 
viaje por la red con esta direccion como origen o destino. 

• Direccion 255.255.255.255 ( broadcast ). Esta direccion solo es 
valida como direccion de destino de un paquete. Se utiliza para 
transmitir paquetes a todas las estaciones localizadas dentro de 
la misma LAN que la maquina de origen. Existe una version 
equivalente, que es el broadcast dirigido. En este segundo caso, 
el paquete es recibido por todas las maquinas de una LAN es- 
pecificada por el identificador de red. El identificador de esta- 
cion debe ser todo 1 . 

Por lo tanto, para enviar un broadcast a la red 147.83.153.0 
con la mascara 255.255.255.0 (o 147.83.153.0/24) podemos uti- 
lizar la direccion 255.255.255.255 si estamos dentro de la red 
147.83.153.0, o bien la 147.83.153.255 si estamos en una es- 



Ejemplo 



La direccion 127.03.87 es 
equivalente a la direccion 
127.0.0.1. 
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tacion remota. El primer caso, lo llamaremos broadcast local, y 
el segundo, broadcast remoto. 

• Todas las direcciones de estos rangos: 

- 10 . 0 . 0 . 0/8 

- De la 1 72.1 6.0.0/1 6 a la 1 72.31 .0.0/1 6. 

- De la 1 92.1 68.0.0/24 a la 1 92.1 68.255.0/24. 

Estas direcciones, que corresponden respectivamente a redes de 
close A, B y C, no son asignadas por Internet, ni nunca lo seran. 
Se utilizan en redes que trabajan con los protocolos TCP/IP pero 
no esta previsto que se conecten directamente a Internet y, en 
caso de que se conectaran, estarian parcialmente ocultas por 
proxies o firewalls, que se encargan de reducir su direccion a otra 
que este en los rangos de direcciones publicas. 

Por tanto, en las redes de close A, B y C no tenemos 2 8 , 2 16 o 2 24 esta- 
ciones posibles, respectivamente, sino 2 8 - 2, 2 16 - 2 y 2 24 - 2. Las di- 
recciones que tienen todos los bits correspondientes a la estacion a 0 y 
las que los tienen todos a 1 no son direcciones validas para estaciones. 



Actividades 

• Indicad a que close pertenecen, cual serla la direc- 
cion de red y la direccion de broadcast remoto de 
cada una de las direcciones IP siguientes: 

- 169.5.10.10/16 

- 124.127.122.123 /8 

- 199.134.167.175/27 

- 201.201.202.202 /24 

- 129.11.189.15/20 

• Una empresa quiere montar una red de ordenado- 
res en un entorno TCP/IP. Para ello, ha decidido 
usar direcciones reservadas para intranet. Concre- 
tamente la red 192.168.206.0, pero solo necesita 
espacio de direcciones para diez estaciones, y se 
plantean hacer una segmentacion de la red. 

- 2Cual serla la mascara mas restrictive para este es- 
cenario? 

- 2Cual serla el rango de subredes posibles? 
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- Suponiendo que la direccion IP de una estacion es 
192.168.206.100, 2cuales serian las direcciones 
del resto de estaciones? 



8.2. El formato del paquete IP 



Figura 26. 




o) Versibn: 4 bits g) Pbsici6n de este fragmento: 13 bits 

b) Longitud de la cabecera: 4 bits h) Tiempo de vida (TTL): 8 bits 

c) Tipo de servicio: 8 bits i) Protocolo: 8 bits 

d) Longitud total dol poquete: 16 bits j) Checksum: 16 bits 

e) Identificacibn del poquete: 16 bits k) Direccibn de origen: 32 bits 

f) Indicadores: (F/ogs) 3 bits I) Direccion de destino: 32 bits 

m) Opciones ontre 0 y rt • 32 bits (n <_1 0) 



A continuacion describiremos los campos que componen el paquete IP: 



• Version: siempre vale cuatro (01 00), para los paquetes de la ver- 
sion actual (IPv4). 



Figura 27. 



Paquete IP 




Cabecera 


Datos 










Version: 4 bit 


fs 
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• Longitud de la cabecera: da la longitud de la cabecera en palabras 
de 32 bits (4 bytes). Por tanto, el numero de bytes de la cabecera 
tiene que ser multiplo de 4. Asimismo, limita la longitud de la cabe- 
cera a 60 bytes (15-4), puesto que 1 5 es el maximo que se puede 
expresar con cuatro dfgitos binarios. Si no hay campo de opcio- 
nes, la cabecera tiene 20 bytes; por tanto, el campo en este caso 
valdrfa 5 (5 • 4 bytes = 20 bytes). 



Figura 28. 




• Tipo de servicio: este campo se encuentra dividido en varios sub- 
campos. Permite pedir un trato especial para el paquete y rara- 
mente se implementa. 



Figura 29. 




• Longitud total del paquete: da la longitud total del paquete (ca- 
becera incluida) en bytes. Como este campo es de 1 6 bits, un pa- 
quete IP no puede tener mas de 65.535 bytes (2 1 6 - 1 ). 



Figura 30. 




Nota 



El campo Tipo de servicio 
permite definir dos variables: 

• El nivel de prioridad 
(del 1 al 8). 

• El tipo de calidad aplica- 
ble al contenido (retardo 
bajo, velocidad alta, fiabi- 
lidad alta, coste bajo, 
etc.). 
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Identificacion del paquete: contiene un identificador que es dife- 
rente para cada paquete que genera la estacion. 



Figura 31 . 




Nota 



Podeis ver la fragmentacion 
de paquetes en el apartado 
8.2.1 de esta unidad. 



• Indicadores (flags) y Posicion de este fragmento: estos campos 
permiten gestionar la fragmentacion de paquetes. 



Figura 32. 



Paquete IP 




Cabecera Datos 




Indicadores (flags): 3 bits 




• Tiempo de vida o TTL ( Time To Live): indica el numero maximo 
de direccionadores que puede cruzar el paquete. Se utiliza 
para evitar que un paquete pueda quedar dando vueltas inde- 
finidamente dentro de la red en caso de que haya algun problema 
al entregarlo. Cada direccionador disminuye el campo en uno; 
cuando uno de ellos detecta un paquete con TTL = 1, lo elimina y 
envfa a quien lo ha emitido un mensaje de error por medio de 
un mensaje ICMP. 
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Paquete IP 



Figura 33. 




Cabecera Datos 




Tiempo de vida [TTL): 8 bits 



• Protocolo: identifica el tipo de protocolo que transporta el paque- 
te. Los valores mas comunes de los diferentes tipos de protocolos 
son los siguientes: 



TCP 


6 


UDP 


17 


ICMP 


1 



Figura 34. 



Paquete IP 




Cabecera Datos 




Protocolo: 8 bits 



• Checksum : realiza el control de errores en la cabecera. El campo 
de datos no queda protegido por ningun checksum; es responsa- 
bilidad de los usuarios del IP (TCP, UDP, etc.) el control de los po- 
sibles errores en su contenido. 



Nota 



Podeis ver una implementa- 
cion en lenguaje C del algorit- 
mo checksum en el anexo 1 . 



Figura 35. 



Paquete IP 




Cabecera Datos 




Cbecfcsu/n : 1 6 bits 
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Not a 

El checksum (o comprobacion por adicion) es basica- 
mente la suma aritmetica de los bytes de la cabecera 
agrupados de dos en dos (si el resultado necesita mas 
de 1 6 bits, se suman los bits sobrantes al mismo resul- 
tado). 

Este algoritmo, si bien es facil y rapido de calcular, no 
se caracteriza por poseer unas grandes cualidades 
para la deteccion de errores. Elio, sumado al hecho de 
que el contenido del IP no tiene checksum y a otros fac- 
tores (tales como que muchos sistemas no calculan el 
checksum de los paquetes UDP), demuestra que en el 
mundo de Internet no existe un interes especial por la 
deteccion de errores. Con frecuencia, este ha sido un 
argumento en el que se han basado los detractores del 
protocolo IP para atacarlo. 

La deteccion de errores dentro del campo de informa- 
cion es responsabilidad de quien entra la informacion. 
Los usuarios mas habituales del IP son los protocolos 
TCP, UDP e ICMP, y todos protegen la informacion con 
un campo adicional de checksum. 



Actividad 

Buscad errores posibles que pasarfan inadvertidos al 
algoritmo checksum. 



• Direccion de origen IP: identifica la maquina que ha generado el 
paquete. 



Figura 36. 
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Direccion de destino IP: identified la maquina a la que va desti- 
nado el paquete. 



Figura 37. 



Paquete IP 




• Opciones: existen diferentes servicios asignados a este campo, 
pero por lo general no se utilizan. Comentarems algunos de los 
mismos cuando hablemos del ICMP. Sea como sea, la longitud 
total esta limitada a 40 bytes (15 -4 — 20). 



Figura 38. 




8.2.1 . Fragmentacion 

Los paquetes IP van siempre insertados en tramas de nivel de enlace 
o MAC. Unos ejemplos que ya hemos visto, son los protocolos PPP y 
Ethernet. 

La mayoria de protocolos de nivel de enlace fijan una longitud maxima 
de datos a transmitir en una trama. Esta longitud se conoce como MTU 
( maximum transfer unit ) y esta determinada por diferentes factores segun 
el caso. En el caso de Ethernet, la MTU vale 1 .500 bytes. 

Cuando una estacion transmite un paquete IP, conoce la MTU de su in- 
terfaz de red, y esta restringida a transmitir paquetes IP cuya longitud sea 
inferior o igual a esta MTU. Si el paquete pasa por un direccionador co- 
nectado a una red con una MTU inferior al tamano del paquete, es pre- 
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ciso fragmentarlo. Los fragmentos resultantes de la operacion son 

paquetes normales, pero con las caracterfsticas siguientes: 

• Todos los fragmentos que provienen de un paquete fragmentado 
tienen el mismo identificador de paquete en las respectivas cabe- 
ceras IP. 

• Todos los fragmentos indican con el campo Posicion de este frag- 
mento a que byte corresponde el primer byte de datos del frag- 
mento dentro del paquete original. El primer fragmento tiene un 
cero en este campo. 

• La parte de datos de cada fragmento contiene un numero de 
bytes multiplo de 8. El ultimo fragmento no tiene porque cumplir 
este requisito. 

• El bit + del campo Indicadores es 1 en todos los fragmentos a ex- 
cepcion del ultimo, que, por el lo se suele denominar hay mas. 

• El resto de los campos de la cabecera se copia mtegramente del 
paquete original a los fragmentos que resultan de la fragmenta- 
cion, excepto el indicador de longitud del paquete y el checksum, 
que se deben calcular de nuevo. 



Figura 39. 



Paquete IP 



Cabecera Datos 



1 bit 1 bit 1 bit 



En principio, podriamos suponer que, cuando los fragmentos vuel- 
ven a una red con una MTU suficiente, el direccionador que los re- 
cibe los reunifica. Sin embargo, no se hace asf, en primer lugar 
porque la ley no escrita de Internet segun la cual el direccionador 
debe llevar a cabo el mmimo trabajo necesario no se cumplirfa. En 
segundo lugar (y mas importante), porque nadie garantiza que to- 
dos los fragmentos sigan el mismo camino. La unica estacion capaz 
de recomponer los fragmentos es la de destino. 



90 





La estacion de destino, cuando recibe un fragmento, reserva suficien- 
te memoria para alojar el mayor paquete IP posible (65.535 bytes), 
puesto que no tiene manera de saber cual es el tamano del paquete 
original. A partir de aquf, pone en marcha un temporizador* y em- 
pieza a recolectar los fragmentos segun su identificador. Cuando se 
han recibido todos los fragmentos, se entrega el paquete a la aplica- 
cion (protocolo) correspondiente. En caso de que el temporizador 
salte, se descartan todos los fragmentos llegados hasta aquel mo- 
menta. El nivel superior (TCP) es el responsable de pedir una retrans- 
mision cuando convenga, puesto que el IP no dispone de ningun 
mecanismo para pedirla. 



Nota 



Este temporizador permite 
detector la perdida de un 
fragmento por el camino y, 
por tanto, la perdida de la 
memoria reservada. 



Nota 

Dentro del campo Indicadores hay dos bits mas que no 
hemos comentado: uno no se utiliza y el otro, el DF 
( Don't Fragment), especifica que el paquete no debe 
fragmentarse. Si fuera preciso fragmentarlo, el paquete 
seria descartado y se enviarfa un mensaje ICMP indican- 
do el error a la estacion originadora del paquete. Usual- 
mente, se activa el bit DF solo cuando la fragmentacion 
no es deseable como, por ejemplo, cuando enviamos 
paquetes a estaciones con la pila TCP/IP implementada 
en ROM, puesto que entonces se implementa solo una 
minima parte de la funcionalidad de TCP/IP. 



Actividad 

Se debe transmitir un datagrama de 4.480 bytes y ne- 
cesita ser fragmentado porque pasara por una red 
Ethernet que admite un maximo de 1 .500 bytes de datos. 
Indicad los valores del campo Longitud del paquete, del 
campo Posicion de este fragmento y del bit + (MF), para 
coda uno de los paquetes IP que se generen. 



8.3. Direccionamiento y direccionadores 



Las atribuciones principales de los direccionadores son interconectar 
dos o mas subredes IP y encargarse de direccionar el trafico destina- 
do a estaciones remotas. 
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Cada direccionador de la red Internet debe ser capaz de decidir (en una 
fraccion de segundo) a donde debe dirigir un paquete basandose exclu- 
sivamente en la direccion de destino, y en el conocimiento que tiene de 
la red y de su posicion (la del direccionador) dentro de Internet. De he- 
cho, cada direccionador no decide la ruta entera del paquete, sino solo 
el trozo de ruta en que participa: el salto (hop) siguiente. Entre el origen 
y el destino tenemos un numero variable de saltos, y en cada uno de 
ellos participan un par de direccionadores (el emisor y el receptor del 
paquete) a excepcion del primero y el ultimo, en que participan las es- 
taciones emisora y receptora, respectivamente. Las conexiones entre di- 
reccionadores, o bien entre direccionador y estacion terminal, las 
componen LAN o enlaces punto a punto. 



Figura 40. 



Transports de on paquete IP a traves de tres subredes 
Origen Direccionador A Direccionodor B Destino 




En la figura anterior, podemos ver un paquete IP que cruza tres redes de 
area local. En cada una el paquete va encapsulado dentro de una trama 
de un tipo adecuado a la subred que cruza (en la figura podrian ser tres 
LAN Ethernet). Las direcciones de origen y de destino del nivel LAN en 
cada tramo son diferentes. En cambio, la direccion de origen y la de 
destino de cada paquete IP no varian. La situacion plantea dos proble- 
mas y, para resolverlos, es preciso efectuar los pasos siguientes: 



Nota 



Podeis ver el ARP en la uni- 
dad 9. 



• Averiguar cual es la correspondencia entre direcciones IP y MAC (so- 
lo en los casos en que el enlace entre los direccionadores sea una 
LAN). Elio nos permitira enviar los paquetes IP a un direccionador a 
pesar de que el paquete IP no tenga su direccion. El mapeado IP- 
MAC se efectua de manera automatica por medio del ARP. 
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Decidir en cada momento cual es el direccionador siguiente (el 
salto siguiente). 









8.3.1. La tabla de direccionamiento 



El direccionamiento se lleva a cabo a partir detablas de direccionamien- 
to que disponen de informacion limitada, pero suficiente para permitir la 
interconexion detodas las subredes que componen Internet. Cada equipo 
conectado a una red IP necesita una tabla de direccionamiento. 



Nota 

Estas tablas se introducen dentro del direccionador 
por medio de un terminal que se conecta al mismo di- 
rectamente (consola). Asimismo, existen protocolos 
que permiten que las tablas se actualicen automatica- 
mente cuando se detectan cambios de topologfa. Los 
mas utilizados son el RIP ( routing information protocol ) 
y el OSPF ( open shortest path first). 



El direccionador decide la ruta de los paquetes consultando su tabla 
de direccionamiento. Las estaciones terminales tambien necesitan 
una tabla de direccionamiento, aunque solo sea para poder descu- 
brir si se estan comunicando con una estacion local de la LAN (y, por 
consiguiente, se pueden comunicar directamente con la misma) o si 
el paquete IP debe ir a una estacion remota (conectada a otra LAN) 
y, portanto, deben dejarlo en manos del direccionador. 



Tabla de direccionamiento de una estacion 
con una unica interfaz 

Empezamos estudiando la tabla de direccionamiento de una estacion 
conectada a una LAN (direccion 147.83.153.103/24) con una unica 
tarjeta Ethernet. Por norma general, una tabla de direccionamiento dis- 
pone tambien de informacion sobre las "cualidades" de cada una de las 
rutas descritas, que no aparecen en el ejemplo: 



Tabla 2. 



Tabla de direccionamiento de la estacion 




Direccion 


Mascara 


Direccionador 


Interfaz 


1 


147.83.153.103 


255.255.255.255 


127.0.0.1 


Loopback 


2 


127.0.0.0 


255.0.0.0 


127.0.0.1 


Loopback 


3 


147.83.153.0 


255.255.255.0 


147.83.153.103 


etherO 


4 


255.255.255.255 


255.255.255.255 


147.83.153.103 


etherO 


5 


0.0. 0.0 


0.0. 0.0 


147.83.153.5 


etherO 
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Nota 



El comando route permite 
consultar y modificar la ta- 
bla de direccionamiento de 
una estacion. Este comando 
esta presente, con este 
nombre, en la mayorfa de 
sistemas operaitvos, inclui- 
dos los GNU/Linux (y, en 
general, todos los sistemas 
Unix). 



Esta es una tabla tfpica que podemos encontrar en una estacion conec- 
tada a Internet. Las filas de la tabla o reglas se consultan no en el orden 
en que el comando route nos las presenta, sino en orden de mascara 
decreciente (en primer lugar, las entradas con 32 bits, etc.). De las en- 
tradas que forman la tabla es preciso senalar lo siguiente: 

• La primera entrada y lasegunda permiten transmitir paquetes 
IP a las direcciones 147.83.153.103 y a todas las direcciones 
que empiecen por 127 (fijaos en la mascara de las dos entra- 
das). En ambos casos los paquetes se envian a la interfaz vir- 
tual loopback (la interfaz con que se conoce el ordenador local 
desde el mismo ordenador local). Ninguno de los paquetes 
que se direccione con alguna de estas dos reglas saldra a la 
red: sera cortocircuitado directamente por el sistema operativo 
y se entregara al proceso de destino sin que nunca llegue a 
ninguna tarjeta de comunicaciones. 



Nota 

Una interfaz es una tarjeta de conexion fisica a la red. 
Ejemplos de interfaz serfan una tarjeta Ethernet (por 
ejemplo, la EtherO) o un puerto serie al que conecta- 
mos un modem. Loopback, como ya se ha comenta- 
do, es un caso especial de interfaz 

Para saber que interfaces hay disponibles en un siste- 
ma GNU/Linux, se dispone del comando ifconfig. 



• La tercera entrada sera adoptada por todos los paquetes desti- 
nados a la red local. El campo Direccionador es el mismo que la 
direccion local, lo que significa que no se delegara su transmision 
a ningun direccionador. 

• La cuarta entrada tiene una importancia relativa. Nos indica 
que los broadcasts IP se restringiran a la red local. 

• La quinta entrada (0.0. 0.0/0) permite a la estacion comunicarse 
con estaciones remotas. Notad que la mascara no tiene ningun 
bit en 1 . Esta es la ruta por defecto. El direccionador establecido 
para acceder a estaciones remotas queda identificado en la tabla 
con la direccion 147.83.153.5. 
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Toda esta informacion se calcula a partir de tres datos que se intro- 
ducer! en la configuracion de red: 



1) La direccion local (en el ejemplo: 147.83.153.103). 

2) La mascara de la LAN local (en el ejemplo: 255.255.255.0). 

3) La direccion del direccionador (en el ejemplo: 147.83.153.5). 

En casos mas complejos (mas de una interfaz de acceso a Internet, 
mas de un direccionador en la red local, etc.), la informacion debera 
modificarse con el comando route. Asimismo, existen otros meca- 
nismos que no requieren la intervencion humana y que permiten des- 
cubrir direccionadores que no se han configurado previamente por 
medio del protocolo ICMP. 



Actividad 

Observad la tabla de direccionamiento de vuestro or- 
denador por medio del comando route. Consultad la 
ayuda disponible en el sistema operativo (en GNU/Linux 
haced man route). 



En un direccionador, las tablas de direccionamiento tienen mas en- 
tradas que las de una estacion; sin embargo, el funcionamiento es el 
mismo que hemos visto en el caso anterior. Observad una que co- 
necta la red 147.83.153.0/24 con el exterior por medio de la red 
147.83.30.0/24: 



Tabla 3. 



Tabla de direccionamiento del direccionador 




Direccion 


Mascara 


Direccionador 


Interfaz 


1 


147.83.153.5 


255.255.255.255 


127.0.0.1 


Loopback 


2 


147.83.30.2 


255.255.255.255 


127.0.0.1 


Loopback 


3 


127.0.0.0 


255.0.0.0 


127.0.0.1 


Loopback 


4 


147.83.153.0 


255.255.255.0 


147.83.153.5 


etherl 


5 


147.83.30.0 


255.255.255.0 


147.83.30.2 


etherO 


6 


255.255.255.255 


255.255.255.255 


147.83.153.5 


etherl 


7 


0.0. 0.0 


0.0. 0.0 


147.83.30.1 


etherO 
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Practicamente no observamos nada nuevo. Simplemente se han dupli- 
cado las entradas especificas de interfaz. El direccionadortambien tiene 
una entrada por defecto. En este caso, todo el trafico no destinado a las 
dos redes a que esta directamente conectado se direcciona hacia otro 
direccionador situado en la red 147.83.30.0 (el 147.83.30.1). 



Actividad 

Pensad si todos los direccionadores de Internet poseen 
una ruta por defecto y razonadlo. Imaginad que sucede 
cuando enviamos un paquete a una estacion de una 
red inexistente (por ejemplo, a la estacion 10.0.1.1). 
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9. Ei ARP ( address resolution protocol) 



Al describir el funcionamiento de los direccionadores hemos visto 
que necesitan saber la direccion MAC correspondiente a una direc- 
cion IP. El ARP es el encargado de llevar a cabo la resolucion auto- 
matica del mapeado entre direcciones MAC. 



Cuando efectuamos la transmision de un paquete entre dos esta- 
ciones locales de una misma LAN, lo hacemos indicando a la apli- 
cacion correspondiente salo la direccion IP. Por ejemplo, si desde 
147.83.153.103 queremos conectarnos a 147.83.153.100, hare- 
mos lo siguiente: 



Nota 



telnet es una aplicacion 
de uso comun para el aceso 
a servidores remotos. La ve- 
remos en la unidad 1 7. 



$ telnet 147.83.153.100 

Aplicando la mascara de red a la direccion IP solicitada, la estacion 
deduce que se encuentra en su misma subred. Por tanto, no hace fa I - 
ta delegar en ningun direccionador. Para poder enviarle las tramas en 
las que deben ir los paquetes IP que genera la aplicacion telnet, ne- 
cesita conocer su direccion MAC. 



Para ello, emite una peticion ARP. Se trata de un paquete encapsulado 
directamente sobre una trama Ethernet (con tipo = 0x0806). Como di- 
reccion de destino lleva la direccion broadcast (FF:FF:FF:FF:FF:FF) para 
que llegue a todas las estaciones de la LAN, y como contenido, la direc- 
cion IP para la cual se desa conocer la direccion MAC. La estacion que 
reconoce su IP en la peticion ARP responde con una respuesta ARP diri- 
gida al origen de la peticion con su direccion MAC. De hecho, el conte- 
nido de la respuesta ARP es irrelevante, lo unico importante es la 
direccion MAC de origen de la trama. 

Lo mismo sucede cuando la estacion deduce que la IP solicitada por al- 
guna aplicacion corresponde a una estacion remota, o sea, de fuera de 
su LAN. En este caso, las tramas se deben enviar al direccionador para 
que se encargue de sacarlas de la LAN hacia su destino. Para ello, la 
estacion origen debe averiguar la direccion MAC del direccionador. 



Nota 



No mostraremos el formato 
de los paquetes ARP, por- 
que no van a aportarnos 
mucha mas informacion. 
Podeis encontrar el formato 
y los usos alternativos del 
ARP en: 

D. E. Comer (1995). 
Internet-working with TCP/IP 
(volumen 1 : "Principles, 
Protocols, and Architecture"). 
Hertfordshire: Prentice Hall 
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Nota 



En rigor, para cada trama 
con paquete IP a generar, 
se tendrfa que hacer una 
peticion ARP. 



Nota 



En GNU/Linux, arp -a sir- 
ve para mostrar la tabla. 
Podeis consultar las paginas 
del manual para el resto de 
opciones. 



Es facil deducir que,en el funcionamiento normal de una estacion,. las 
peticiones ARP pueden ser muy habituales. Para evitarlo, cada estacion 
dispone de una tabla las parejas ya obtenidas, de forma que si una di- 
reccion IP ya se encuentra es dicha tabla, no hace falta enviar ninguna 
peticion ARP. Dicha tabla se denomina cache ARP, y tiene el siguiente 
aspecto: 



Tabla 4. 



Tabla cache ARP 




Direccion IP 


Direccion MAC 


Interfaz 


1 


147.83.153.103 


08:00:00:10:97:00 


etherO 


2 


147.83.153.5 


00:0c:aa:00:0f:e0 


etherO 



Cada fila corresponde a un mapeo IP-MAC y la interfaz para la cual se 
ha solicitado. 

Esta tabla se va llenando automaticamente a medida que se realizan 
nuevas peticiones, pero tambien se puede manipular con el comando 
arp. Con el se puede consultar, anadir o borrar entradas. 

La tabla ARP se denomina cache porque, de hecho, actua como una 
memoria auxiliarque evita la consulta de la informacion a la LAN mien- 
tras se tenga una copia local de la misma. Puede parecer que la consul- 
ta ARP no deberia ser demasiado frecuente, puesto que al cabo de cierto 
tiempo toda la informacion se encontrarla dentro de la cache. Conviene 
saber, sin embargo, que las entradas caducan al cabo de un periodo de 
tiempo relativamente breve (entre uno y unos cuantos minutos, segun el 
sistema). 



Actividad 

Imaginad que podrfa suceder si las entradas de la ca- 
che ARP no caducaran. Os puede servir de ayuda pen- 
sar en la reconfiguracion de direcciones. 



Algunos usos alternatives de interes del ARP son los siguientes: 
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ARP innecesario ( gratuitous-ARP ): se utiliza cuando una estacion 
arranca para saber si hay alguna otra estacion que esta utilizando 
su misma direccion IP. Por medio de una peticion ARP, puede pre- 







guntar quien tiene su direccion IP (un conflicto de este tipo podria 
dejar las dos estaciones "fuera de combate"). 

• ARP subsidiario ( proxy-ARP ): se utiliza en situaciones en las que 
un direccionador divide una subred sin que las estaciones ni el di- 
reccionador que los conecta a Internet modifiquen su mascara. 
Esta tecnica, a pesar de no ser demasiado ortodoxa, se aplica con 
frecuencia cuando el direccionador de una red privada se conecta 
a Internet por medio de una red ajena (un proveedor de Internet, 
por ejemplo). 



Actividad 

Consultad la cache ARP de algun sistema que tengais 
al alcance (Unix o MS) por medio dearp -a. Compro- 
bad que opciones tiene disponibles. 
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10. El ICMP (Internet control message protocol ) 



La cuestion de si el ICMP es un protocolo, o si mas bien es una herra- 
mienta que utiliza el protocolo IP para notificar errores genera mucha 
polemica. Lo cierto es que el ICMP constituye el mecanismo basico 
para lagestion de las diferentes incidencias que pueden ocurrir en una 
red IP. 



10.1. Mensajes ICMP 



Los mensajes ICMP viajan dentro de paquetes IP (al contrario de lo 
que sucedia con los paquetes ARP), en el campo de datos con el cam- 
po Protocolo igual a 1. El formato del mensaje presentado en la fi- 
gura siguiente nos facilitara el estudio de los diferentes usos del 
paquete ICMP: 



Figura 41 . 



Paquete IP 




a) Tipo: B bits 

b) Codigo: 8 bits 

c) Cheksum: 16 bits 

d) Contenido (depende de) tipo de mensaje) 



Existen trece tipos de mensajes ICMP en uso en la actualidad, y al- 
rededor de una treintena de subtipos identificados con el campo 
Codigo. 
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Tabla 5. 



Tipo 


Codigo 


Descripcion 


Clase 


0 


0 


Respuesta de eco ( echo reply ) 


Peticion 


8 


0 


Peticion de eco ( echo request) 


Peticion 


3 


0-15 


Destino inalcanzable ( unreachable destination ) 
Los diferentes codigos permiten definir si lo 
que no se puede alcanzar es la subred (0, 6, 9, 
1 1 ), la estacion (1 , 7, 1 0, 1 2), el protocolo (2), 
o el puerto (3) y los motivos 


Error 


4 


0 


Peticion de control de flujo ( source quench ) 


Error 


5 


0-3 


Redireccionamiento 


Error 


9 


0 


Publicacion de rutas 


Peticion 


10 


0 


Peticion de rutas 


Peticion 


11 


0-1 


El tiempo de vida ha expirado ( time exceeded ) 


Error 


12 


0-1 


Cabecera IP incorrecta 


Error 


13 


0 


Peticion de hora 


Peticion 


14 


0 


Respuesta de hora (en milisegundos desde la 
medianoche) 


Peticion 


17 


0 


Peticion de la mascara de la subred 


Peticion 


18 


0 


Respuesta de la mascara de la subred 


Peticion 



La ultima columna nos permite distinguir mensajes ICMP de notifica- 
cion de error de mensajes que son parte de una peticion (la peticion 
o la respuesta). Esta distincion es importante, puesto que los mensa- 
jes de error ICMP no pueden generar otros mensajes de error ICMP. 
En particular, no se generan mensajes de error en respuesta a los pa- 
quetes o mensajes siguientes: 



• Los mensajes de error ICMP. 

• Un paquete IP destinado a una direccion broadcast (sea un 
broadcast IP o un broadcast MAC). 

• Un fragmento que no sea el primero. 

• Una direccion de origen que no identifique una unica estacion. 
Por ejemplo, la direccion de origen valida 0.0. 0.0 o la direccion 
de origen no valida 255.255.255.255. 





En cualquiera de las situaciones que acabamos de des- 
cribe se pueden provocar respuestas en cascada que 
podrfan afectar gravemente a la red. 



Not a 

Parches 

Desgraciadamente, no todas las implementaciones 
TCP/IP han tenido en cuenta las excepciones existentes 
en la generacion de mensajes de error, y algunos usua- 
rios desaprensivos han explotado estos problemas para 
bloquear sistemas y redes remotas. Asimismo, de vez en 
cuando se descubren nuevas excepciones que pueden 
afectar a nuestros sistemas. 

Los fabricantes de sistemas operatives publican re- 
gularmente parches (patch) que permiten solucionar 
los problemas (las vulnerabilidades) que se han des- 
cubierto desde la fecha de publicacion de la ultima 
version. 



10.2. El programaping 



El programaping permite descubrir si una estacion se encuentra ac- 
tiva o no, simplemente efectuando lo siguiente: 

$ ping <direccion_IP_destino> 

El programa ping envfa un mensaje ICMP del tipo 8 (peticion de 
eco) con el destino indicado. El receptor de la peticion debe respon- 
der con una respuesta de eco (ICMP tipo 0), y, cuando el ping la re- 
cibe, indica en pantalla que la estacion remota esta activa. 
Evidentemente, el programa deberfa llamarse ping-pong. 
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Figura 42. 



Mensaje ICMP de peticidn de eca Mensaje ICMP de respuesta de eco 
Pbquete IP Paquete IP 




Tipo C6digo Checksum Datos Tipo C6digo Checksum Datos 




(Tiempo, 


(Tiempo, 


rollcno, etc.) 


relief*), etc.) 


El campo Tipo es igoal a 8. 


B campo Tipo e* igual a 0. 



Actividad 

Practicad el uso del programa ping. Comprobad que 
retardos maximos se dan en Internet. Hacedlo a dife- 
rentes horas del dia. 

Con el ping tenemos otras opciones disponibles. En particular, la 
opcion de memorizacion de rutas (record route o RR; ping -R, en 
GNU/Linux), que no se refleja en ninguno de los campos del mensa- 
je ICMP, sino que se encuentra dentro de la misma cabecera IP, en 
el campo de opciones. 



Las diferentes opciones que se 
encuentran disponibles en la 
cabecera se identifican por me- 
dio del primer byte del campo 
de opciones de la cabecera IP 
(figura 43). 

Si el originador, porejemplo, quie- 
re activar la opcion RR, el primer 
byte debe ser 7. Sea como sea, en 
todas las opciones el primer byte 
indica el tipo, y el segundo, la lon- 
gitud en bytes de la opcion. 



Figura 43. 




Opciones 



a) Tipo de opcion: 8 bits 

b) Longitud de la opcidn: 8 bits 
c| Puntero actual: 8 bits 
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En este caso siempre se pide el maximo posible, que es 39 bytes, 
puesto que el campo siguiente tiene un byte (puntero), al que sigue 
una cadena de campos de 4 bytes (que son las direcciones IP encon- 
tradas). El campo Puntero se inicializa a 4, y dentro de los 4 bytes si- 
guientes se guarda la direccion de la estacion en que ejecutamos el 
ping. 

Cada direccionador debe mirar dentro de los paquetes IP (ICMP o 
no) para ver si tienen la opcion RR activada. Si un direccionador en- 
cuentra un paquete con esta opcion activada, modifica la posicion 
apuntada por el puntero con su direccion (por norma general, la di- 
reccion de salida del direccionador) e incrementa el valor del pun- 
tero en cuatro unidades. Cuando vuelve el mensaje de respuesta de 
eco, se ha anadido una lista con todos los saltos que ha tenido que 
realizar el paquete (tanto de ida, como de vuelta). 

El campo de opciones tiene limitaciones de tamano: solo dispone de 
36 bytes (39 - 3) para guardar direcciones IP. Como cada direccion 
ocupa 4 bytes, solo hay espacio para nueve direcciones IP. Si a el lo 
le anadimos que no todos los direccionadores comprueban si hay 
opciones dentro de los paquetes IP, o no actualizan la opcion RR, 
hace poco util este tipo de ping en el mundo real. 



Actividad 

Comprobad la ruta a diferentes destinos por medio de 
un ping con la opcion de memorizacion de rutas. Valo- 
rad si la comprobacion de esta opcion esta muy exten- 
dida. 



10.3. El programa traceroute 

El programa traceroute permite encontrar las rutas entre un 
origen y un destino sin ninguna de las limitaciones del ping -R. Uti- 
liza un mecanismo bastante ingenioso basado en mensajes gene- 
ricos ICMP (y no los especificos peticion de eco y respuesta de eco 
del ping). 
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El funcionamiento se basa en la explotacion de dos mensajes 
ICMP: 



1) Tiempo de vida agotado ( time-exceeded ): cuando un direc- 
cionador recibe un paquete, aparte de las tareas primordiales 
de direccionamiento, debe reducir en una unidad el valor del 
campo TTL de la cabecera IP. 

En caso de que el valor (despues de la reduccion) sea cero, el 
paquete debe eliminarse. Sin embargo, esta eliminacion no es 
silenciosa, sino que el direccionador responsable envfa una 
notificacion de la misma al originador del paquete por medio 
de un mensaje ICMP tipo 1 1 y codigo 0 (tiempo de vida ago- 
tado). 

Este paquete ICMP contiene la cabecera del paquete IP que se 
ha eliminado y los primeros 8 bytes de su contenido (segura- 
mente la cabecera UDP o los primeros bytes de la cabecera 
TCP). 



Figura 44. 




2) Puerto inalcanzable (unreachable-port): cuando una estacion re- 
cibe un datagrama UDP o un segmento TCP destinado a un puer- 
to que la maquina no escucha, responde con un mensaje de error 
de puerto inalcanzable (tipo 3 con codigo 3). 
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Figura 45. 




a) Tipo= 3 

b) Codigo* 3 

c) Checksum 

d) No utilizados (los 32 bits estan a 0) 

e) Cabecera IP con las opciones y 8 bytes 
del contenldo original del paquele IP 



El programa traceroute simplemente debe enviar paquetes al 
destino con TTL secuencialmente ascendentes: el paquete (con in- 
dependence del tipoque sea) que tenga el TTL= 1 sera rechazado por 
el primer direccionador, el que tenga TTL= 2 lo sera por el segundo, 
y asf consecutivamente. Cada uno de los direccionadores devolvera 
un mensaje ICMP "tiempo de vida agotado", una pista del todo sufi - 
ciente para que el originador averigue el camino que han seguido 
todos los paquetes. 

Cuando el mensaje llega al destino, debe devolver algun mensa- 
je para saber que la secuencia ha finalizado. Por norma general, 
el mensaje sera "puerto inalcanzable" si el mensaje enviado era 
un datagrama UDP a un puerto no usado, o bien una respuesta 
de eco si lo que se ha enviado son paquetes ICMP de peticion de 
eco. 



Actividades 

Utilizad el programa traceroute para descubrir los 
caminos que siguen diversos paquetes hasta diferen- 
tes destinos. 

Probad que sucede si nos conectamos a un puerto no 
servido. Por ejemplo, conectaos al puerto TCP 1234 
(podeis hacerlo con Telnet localhost 1234). 
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10.4. Mensaje de redireccionamiento 

Es normal que los sistemas se conecten a Internet solo configurando 
su direccion IP, la mascara de la LAN y el direccionador que gestiona 
la comunicacion remota. Cuando hay mas de un direccionador en la 
LAN local, puede darse el caso de que para algunas rutas sea mejor 
usar otro direccionador y no el que tenemos configurado. 

A este efecto, los direccionadores disponen del mensaje ICMP de re- 
direccionamiento (redirect), que actua de la manera siguiente: 

1 ) La estacion envia un paquete al direccionador que tiene configu- 
rado (A). El direccionador A descubre que la mejor ruta pasa por 
utilizar el direccionador B. 

2) El direccionador A direcciona el paquete hacia el direccionador B. 

3) Notifica a la estacion que modifique su tabla de direccionamiento. 



Figura 46. 




Notad que, normalmente, el direccionador continua direccionando 
los paquetes (paso 2). Aunque la estacion no hiciera caso del men- 
saje ICMP de redireccionamiento (paso 3), continuarfa teniendo co- 
nectividad con el exterior; sin embargo, si le hace caso, mejorara el 
rendimiento del sistema. 
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Cuando una estacion obedece a un ICMP de redireccionamiento, su 
tabla de direccionamiento queda convenientemente actualizada. El 
comando route puede proporcionarnos alguna pista de si este fe- 
nomeno tiene lugar. 
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1 1 . Redes de acceso a Internet 



Las redes de acceso a Internet mas habituales son la red telefonica 
(por modem) que se utiliza, sobre todo, en el ambito domestico, el 
ADSL (asymetric digital subscriber line, linea de abonado digital do- 
mestica) que, aunque utiliza la infraestructura de acceso de la red te- 
lefonica, no se puede decir que vaya sobre la linea telefonica, y la 
Ethernet. 

1) En accesos por medio de la red telefonica y, en general, en ac- 
cesos por medio de redes conmutadas (incluyendo el acceso por 
la RDSI), se suele utilizar el PPP ( point-to-point-protocol ). 



Nota 

Si bien durante mucho tiempo se han utilizado el SLIP 
( serial line Internet protocol) y el ( compressed SUP), en 
la actualidad se han dejado practicamente de lado 
en favor del PPP, que tiene mas flexibilidad (permite 
gestionar automaticamente ciertos parametros IP y 
multiplexor, dentro de la misma conexion, diferentes 
protocolos de interconexion, aparte del IP) y es mas fia- 
ble (dispone de CRC en cada trama). 



2) En LAN, el protocolo que se utiliza en mas del 90% de los casos 
es la Ethernet. Nosotros nos centraremos solo en los detalles de 
las direcciones de dicho protocolo, puesto que es lo unico que 
afecta a la manera de funcionar del IP. 



Casi todos los protocolos de LAN que componen el 10% restan- 
te (IEEE802.3 CSMA/CD, IEEE802.5 Token Ring, etc.) utilizan 
una estructura de direcciones identica a la de Ethernet. De he- 
cho, podriamos hablar de compatibilidad, puesto que la asig- 
nacion de direcciones se hace globalmente para todas las LAN 
mencionadas y la gestiona el IEEE (Institute of Electric and Electronic 
Engineers). 
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11.1. Acceso telefonico: el PPP 



El PPP es fundamentalmente un protocolo derivado del HDLC 
( high-level data link protocol ) para conexiones balanceadas 
(HDLC-ABM, HDLC-asynchronous balanced mode). El formato de 
la trama PPP se representa en la figura siguiente: 




Los campos Indicador (flag), Direccion y Control estan fijados en los va- 
lores de la figura anterior. El campo Direccion tiene el valor 11111111, 
que es el de difusion o broadcast en la mayorfa de los protocolos (por 
ejemplo, en todos los HDLC). Elio significa que este campo (como el de 
control) no se utiliza. Su utilizacion en el PPP solo se puede justificar por 
el posible uso de tarjetas HDLC genericas para conexiones PPP. Como 
cualquier protocolo HDLC, debe aplicar el mecanismo de transparencia 
de insercion de ceros (bit stuffing). 



Nota 

El PPP especifica una variante orientada a caracter (los 
protocolos de la familia HDLC estan orientados a bit), 
que es la que mas se utiliza en enlaces por medio de 
modem (un contraejemplo sedan las conexiones me- 
diante la RDSI). 



Lo importante es lo que transportan las tramas PPP. El mismo estan- 
dar define la multiplexacion de diferentes protocolos, que se distin - 
guiran por medio del campo Tipo. Los que nos interesan son los 
siguientes: 

• LCP (link control protocol ): es el protocolo encargado de realizar 
el test del enlace, el control de la conexion y la gestion del enlace. 

112 







• Protocolos de red : son tramas que encapsulan paquetes de ni- 
vel superior, como puede ser IP. Pero tambien pueden trans- 
porter NETBEUI, AppleTalk, Decnet, etc. 

• NCP ( network control protocol): es el protocolo que se utiliza 
para tareas de gestion de los protocolos de red que transporta 
el enlace. En el caso del IP, permite que uno de los terminales 
asigne la direccion de Internet al otro y configure los diferentes 
parametros de la red (direccionador, mascara, etc.) 




11.1.1. Compresion de las cabeceras 

Como ya hemos visto, la piramide de PDU provoca ineficiencias en 
la transmision, sobre todo en protocolos como Telnet, que con fre- 
cuencia envian bloques muy cortos de informacion. Asimismo, el PPP 
se ha utilizado en enlaces telefonicos que funcionan a velocidades 
maximas teoricas de entre 9.600 bps (modems norma V.32) y 
33.600 bps (modems norma V.34). Elio hace que dicha ineficiencia 
sea todavia mas grave. 
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Not a 



Si se utiliza Telnet, para enviar un caracter (de 1 byte) 
debemos enviar 8 + 20 + 20 + 1 = 49 bytes. Con 
un modem de 9.600 bps, si utilizaramos mensajes de 
8 bits de longitud mas 1 bit de arranque y 1 bit de pa- 
rada, podrfamos transmitir: 

9.600/ (1 + 8 + 1) = 960 caracteres/segundo. 

De hecho, nadie es capaz de mecanografiar tan rapi- 
do. Sin embargo, no debemos perder de vista que el 
enlace puede ser compartido por otras conexiones 
(transferencia de ficheros, consulta de la web, etc.). 

La compresion de cabeceras Van Jacobson mejora considerable- 
mente este problema. Este tipo de compresion se basa en el hecho 
de que en un acceso a Internet con PPP, en general no habra dema- 
siadas conexiones TCP simultaneas. La compresion Van Jacobson 
permite mantener una tabla de hasta dieciseis conexiones simultaneas 
TCP/IP, a las que asignara dieciseis identificadores diferentes. Como la 
mayona de los campos de las dos cabeceras TCP/IP no varfan durante el 
transcurso de una misma conexion, basta con tener entre 3 y 5 bytes de 
cabecera para cada paquete (combinando PPP y TCP/IP) para mante- 
ner un funcionamiento correcto de la conexion. La ganancia en efi- 
ciencia de la transmision es suficientemente importante. 

Para saber con exactitud que ganancia se consigue, precisamos sa- 
ber que longitud pueden tener las tramas PPP. 

Por medio del LCP tambien pueden obtenerse otras mejoras como, 
por ejemplo, la eliminacion de los campos de control y de direccion. 



11.1.2. MTU 

Como ya hemos comentado, la mayona de protocolos de nivel de 
enlace poseen una longitud maxima de transmision, la MTU, que 
condiciona el tamano de los paquetes de nivel superior que tanspor- 
ta. En el PPP, protocolo derivado del HDLC, no se trata de un valor 
concreto, sino que el Ifmite vendra fijado por la probabilidad de error 
en un bit que tengamos: cuanto mas larga sea la trama, mas proba- 
bilidad existe de que sea erronea. 
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Sin embargo, existe un factor que limitara la MTU mas que los Ifmites 
impuestos por los protocolos: el confort de la conexion. Se ha demos- 
trado que, en conexiones en tiempo real (como una conexion Telnet), el 
usuario debe recibir una reaccion a sus acciones en una decima de 
segundo como maximo. retardos superiores provocan cansancio y 
dan la sensacion de que "la maquina va lenta", que todos hemos ex- 
perimentado alguna vez. 

Si pensamos que dentro de la misma conexion podemos tener mul- 
tiplexadas otras de transferencia (como FTP o web), nos encontrare- 
mos que los paquetes de las aplicaciones en tiempo real, que suelen 
ser cortos, deben esperarse detras de los paquetes de longitud maxi- 
ma que se utilizan en las aplicaciones que tienen una tasa de trans- 
mision elevada (supondremos que los paquetes de la aplicacion en 
tiempo real tienen preferencia sobre otros que previamente estuvie- 
ran en la cola de salida). 

La unica manera de hacer que una aplicacion estandar de transfe- 
rencia utilice paquetes mas pequenos es reducir la MTU de la co- 
nexion. En el caso del PPP, si tomamos como referencia un modem 
de 33.600 bps, tenemos que un paquete de una decima de segundo 
de duracion tendria los bytes siguientes: 

33.600 bps • (0,1 s) • (1 byte / 8 bits) = 420 bytes. 

En conexiones PPP tendremos, pues, la MTU entre 250 y 500 bytes. 
Con modems que dispongan de compresion, los valores que obten- 
dremos pueden aumentar. 



Not a 

Las velocidades de transmision de los modems estan- 
dar son 9.600 bps (V. 32) , 14.400 bps (V.32bis) y 
33.600 bps (V.34). 

En general, los modems disponen de dispositivos 
electronicos para comprimir y descomprimir datos. 
Los estandares V.42bis y MNP9 realizan compresio- 
nes de hasta 1 :4, con lo que pueden lograr velocida- 
des de transmision efectiva de hasta 134.400 bps 
(V.34 + V.42bis) en situaciones favorables. 
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Hay modems (los que siguen el estandar V.90) que 
pueden lograr velocidades de hasta 56 kbps. En rea- 
lidad, no son modems en el sentido estricto, puesto 
que necesitan que en el otro extremo de la linea haya 
un codec conectado a una linea digital. 



1 1 .2. Acceso ADSL 

Si bien el acceso a Internet por modem por medio de PPP ha sido 
la manera habitual de conexion por parte de los usuarios domes- 
ticos y las pequenas empresas durante la primera "decada Inter- 
net", parece que el lo cambiara y en la segunda "decada Internet" 
se adoptaran sistemas que faciliten la conexion permanente. 



Nota 

La conexion por modem ocupa la linea de telefono del 
abonado y, lo que todavfa es peor, establece una lla- 
mada durante un tiempo indefinido. 



El ADSL representa una solucion a este problema, puesto que, por un 
lado (aunque utiliza el cableado de la linea telefonica, el bucle de abo- 
nado), la linea telefonica queda libre para llamadas mientras se esta 
conectado a Internet y, por otro, la conexion no consume recursos de 
la red telefonica, puesto que, cuando la serial llega a la centralita, se 
extrae del bucle de abonado y pasa a la red IP de la operadora. 



Figura 49. 




116 





En general, el direccionador que hay en el domicilio del usuario ofrece 
una conexion Ethernet equivalente a un concentrador, lo que permite que 
el abonado conecte mas de un ordenador por medio de la Ifnea ADSL. 



Para permitir que la Ifnea telefonica conviva con la conexion a Inter- 
net permanente, se realiza una division del espectro: la parte baja 
continua ocupada por el canal de voz (hasta 4 kHz) y, a partir de 
aquf, se situa el espectro de la codificacion ADSL (con la limitacion 
propia del parde hilos). El sistema es bidireccional: reserva el espec- 
tro bajo para la salida a la red, y el resto, para la entrada: 



Figura 50. 



Espectro de frecuencia ADSL 


LI 







25kNz 150 kHz 






Serviclo Usuario -► Red 
lelefdnico (Upstream) 



1,1 MHz 



Red -► Usuario 
(Downs/ream) 



Nota 



Algunas operadores, para 
aprovechar mejor lineas ma- 
las, utilizan una variante del 
estandar que permite la 
transmision bidireccional con 
los dos canales en la misma 
banda. 

Esta solucion, aunque nece- 
sita DCE mas caros, permite 
aprovechar lineas con peo- 
res condiciones y/u obtener 
velocidades mas altas. 



Generalmente, no se puede llegar a los 1 ,1 MHz que indica la figura, 
puesto que la calidad del par de hilos es muy variable (clima, longi- 
tud, edad, etc.), por lo que se utiliza una codificacion adaptativa: los 
dos sentidos del canal se dividen en subbandas de 4 kHz indepen- 
dientes (DMT, discrete multitone ) que se codifican (en realidad, se 
modulan) con procedimientos casi identicos a los utilizados por los 
modems tradicionales. Con el lo, se consiguen treinta y dos canales 
de salida y hasta doscientos cintuenta y seis de entrada, con una ca- 
pacidad de 60 kbps cada uno de los mismos -modulados en QAM 
( quadrature amplitude modulation ), como los modems telefonicos- 
que, acumulados, proporcionan un maximo de 15,36 Mbps de en- 
trada y 1 ,92 Mbps de salida. 



No obstante, las mejores conexiones no consiguen aprovechar correcta- 
mente los canales superiores y se considera que el Ifmite maximo de sali- 
da es de 8 Mbps. Asimismo, las operadoras no suelen ofrecer conexiones 
tan rapidas, lo que hace que no se pueda lograr el Ifmite teorico. 



Los protocolos utilizados dentro del ADSL dependen de la operadora 
y no estan definidos por el estandar. Entre los posibles protocolos 
para el ADSL, tenemos el ATM y el mismo PPP. 
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1 1 .3. Acceso LAN: el protocolo Ethernet 



Seguramente, la simplicidad de este protocolo de red, y no sus pres- 
taciones teoricas, ha hecho que sea el mas utilizado en redes de area 
local practicamente desde que DEC, Intel y Xerox establecieron un 
estandar (de facto ) para LAN con control de acceso al medio CSMA/ 
CD, basandose en una arquitectura similar desarrollada los anos se- 
tenta por Xerox. 



Hay un principio que se cumple en todas las redes de 
area local: lo que una estacion transmite es recibido 
por todas las demas. Una estacion sabe cuando una 
trama le va destinada porque lee todas las que le Me- 
gan y comprueba la direccion de destino. Tiene que 
rechazar todas las tramas con direcciones que no 
sean la suya. Sin embargo, tambien hay excepciones, 
y en algunos casos las estaciones tambien deben cap- 
turar tramas dirigidas a direcciones especiales (como 
las multicast y las broadcast ). 



Not a 

Uno de los casos en el que una estacion no rechaza 
las tramas con direcciones diferentes de la suya es 
cuando la estacion configura la tarjeta de red en 
modo promiscuo. En este modo, la tarjeta inhabilita 
su capacidad de filtrado y lee todas las tramas que 
pasan por la red. Equipos que, generalmente, fun- 
cionan en este modo son los puentes ( bridges , siste- 
mas destinados a la interconexion de LAN), los 
analizadores de trafico (o analizadores de red) o los 
conmutadores (switches). No obstante, casi todas las 
tarjetas se pueden configurar en modo promiscuo, lo 
que con frecuencia es aprovechado por los ladrones 
de informacion ( hackers ) para leer y copiar informa- 
cion interesante que viaje por la LAN (principalmente 
contrasenas). 
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11.3.1. Formato de la trama Ethernet 



La manera de conocer las principales caracterfsticas de la trama 
Ethernet es ver los diferentes campos que la forman, que son los si- 
guientes: 




a) Preambulo: esta formado por 64 bits, alternativamente 0 y 1 . Los 
dos ultimos son 1 1 . Elio genera una serial cuadrada que permite a 
los terminales sincronizar adecuadamente los relojes de sincronismo 
de bit. Los dos ultimos bits senalan donde empieza la trama (sincro- 
nismo de trama). Su forma es identica en todas las tramas. Nosotros 
obviaremos su presencia en el resto de la explicacion, puesto que 
solo son una serial para marcar el inicio de la trama. 

b) Direccion de origen: Neva la direccion ffsica o direccion AAAC del 
transmisor de la trama. Son 48 bits diferentes para cualquier ter- 
minal de la red Ethernet. 

c) Direccion de destino: Neva la direccion AAAC del destinatario es- 
pecificada de la misma manera (en el mismo formato) que la di- 
reccion de origen. En este caso, sin embargo, tenemos tres tipos 
de direcciones posibles: unicast, multicast y broadcast. 

d) Tipo: indica el tipo de contenido del campo de datos que lleva 
la trama (las tramas que transportan paquetes IP llevan un 
0x800). Permite multiplexor diferentes protocolos dentro de 
una misma LAN. Xerox actualiza regularmente la lista de pro- 
tocolos registrados (Xerox Public Ethernet Packet Type). Mas 
adelante veremos las variedades de protocolos de Ethernet 
para conocer las variantes de Ethernet semicompatibles y saber 
como afecta su coexistencia a la manera como Ethernet ha te- 
nido que definir el campo Tipo. 
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Actividad 

Consultad la lista de los protocolos registrados para 
haceros una idea de la cantidad de protocolos de red 
(los superiores a Ethernet) que hay. 



e) Datos: se refiere al formato del campo de datos. Las restricciones 
sobre el tipo de datos que puede transporter Ethernet son las si- 
guientes: 

• La longitud de los datos debe ser multiplo de 8 bits; es decir, 
Ethernet transporta la informacion en bytes. Elio no es ningun im- 
pediment©, puesto que los bits los envfan sistemas que, por nor- 
ma general, trabajan con bytes o multiplos de bytes. 

• Del mismo modo que PPP, Ethernet tiene limitada la longitud 
maxima de informacion transportable por la trama (MTU). En este 
caso, la MTU es de 1 .500 bytes. Esta limitacion tiene como obje- 
tivo evitar que una estacion monopolice la LAN. 

• El campo de datos debe tener como minimo 46 bytes de longi- 
tud (en Gygabit Ethernet, 51 2). Elio se debe al hecho de que es 
preciso que la trama minima Ethernet tenga 64 bytes (51 2 bits). 
Se considera que las tramas inferiores son resultado de colisiones 
y son obviadas por los receptores. 

Este problema no se plantea en la variante de Ethernet IEEE802.3, 
puesto que este protocolo dispone de un campo de longitud y otro 
de relleno ( padding ) que permiten transmitir datos de hasta 1 byte de 
longitud, aunque la longitud que ffsicamente se transmite continua 
siendo de 64 bytes. 



Actividad 

Imaginad que sucederfa si una estacion quisiera en- 
viar un fichero de 1 GB por la LAN dentro de una sola 
trama. 



f) CRC: es un codigo de redundancia cfclica de 32 bits (CRC-32) 
para la deteccion de errores. Abarca toda la trama a excepcion 
del preambulo. Las tramas que no poseen un CRC correcto se ig- 
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noran (como las tramas de menos de 64 bytes y las que no son 
multiples de 8 bits). 



Not a 

Desde mediados de los anos ochenta Ethernet ha convi- 
vido con una variante similar denominada IEEE802.3 o 
ISO8802.3. Son estandares establecidos por organiza- 
ciones reconocidas (el IEEE y la ISO) dedicadas a la nor- 
malizacion (estandar de iure). Durante un tiempo se 
penso que el IEEE802.3 acabaria sustituyendo a la Ether- 
net original (tambien denominada Ethernet-DIX, en honor 
a DEC, Intel y Xerox), que no podia transmitir tramas ar- 
bitrariamente pequenas. Los protocolos que trabajan so- 
bre Ethernet-DIX conocen esta limitacion y Henan la 
trama hasta ocupar los 46 bytes de informacion. 

El IEEE802.3 introduce un campo de longitud (en la 
misma posicion en que Ethernet tiene el campo de 
tipo) que permite saber cuantos bytes utiles contiene 
el campo de datos. Si la longitud no llega a los 46 
bytes minimos, se llena con bytes (indefinidos) hasta 
llegar al minimo. El receptor solo debe leer el campo 
de longitud para extraer la informacion valida del 
mismo. El concepto de tipo de Ethernet (es decir, la 
coexistencia de diferentes protocolos por encima de 
Ethernet/IEEE802.3) se delega a un protocolo aso- 
ciado: el IEEE802.2, protocolo de enlace que se 
puede utilizar en el IEEE802.3 y en otros protocolos 
de LAN y que posee unas funciones similares a las 
del HDLC. 



Figura 52. 
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Como en el nivel fisico ambos estandares son totalmente 
compatibles, podriamos preguntarnos si pueden coexis- 
tir tramas Ethernet-DIX e IEEE802.3 dentro de una 
misma LAN. La respuesta es que si y que no al mis- 
mo tiempo. 

Fijaos en que todos los campos de la trama Ethernet 
y de la 802.3 son del mismo formato y significan lo 
mismo, a excepcion del campo de tipo (Ethernet) y 
de longitud (802.3). Podriamos distinguirlos siempre 
que vigilaramos que ningun tipo Ethernet fuera equi- 
valente a una longitud valida de 802.3. Los tipos 
con valores inferiores a 1 .500 (0x5DC en hexadeci- 
mal) pueden confundirse con longitudes validas. 

Elio, obviamente, no podia tenerse en cuenta en la 
Ethernet-DIX original, puesto que es anterior al 
IEEE802.3. Por el lo, aparecio una adenda a la nor- 
ma Ethernet-DIX, conocida como Ethernet-DIX-ll, 
que elimina los identificadores de protocolos por de- 
baio de 0x0600 (1.536 en decimal). Hoy dia con 
frecuencia dentro de una misma LAN encontramos 
tramas Ethernet-DIX-ll y tramas IEEE802.3. 

El IP puede ir sobre cualquiera de los dos estandares, 
aunque casi nadie elige la posibilidad de encapsularlo 
sobre el IEEE802.3. El par de protocolos IEEE802.3 + 
802.2 se utiliza en algunos de los sistemas operativos de 
red aparecidos en los anos ochenta como, por ejemplo, 
el IPX de Novell y el NETBEUI de Microsoft. 



11.3. 2. Tipos de medios fisicos en Ethernet 

Ethernet se ha ido adaptando a las necesidades del tiempo am- 
pliando los subestandares de nivel fisico. A continuacion, mostra- 
mos una lista de los estandares mas utilizados: 

• 10Base2: alcance de 185 m, 6 925 m con repetidores, pero 
con coaxial delgado, flexible y barato (por el lo, durante mu- 
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chos anos esta red se ha denominado Cheapernet). aunque 
hoy dla se tiende gradualmente a dejarlo de lado en favor de 
1 OBaseT -que es mucho mas fiable-, millones de terminales en 
todo el mundo estan conectados con Ethernet-1 0Base2. Se uti - 
liza sobre todo en topologlas en bus. 

• 1 OBaseT: conexion en estrella de las estaciones a un nudo cen- 
tral (concentrador o hub) por medio de partrenzado; la distan- 
cia maxima de la estacion al concentrador es de 100 m. La 
distancia maxima entre estaciones se consigue encadenando 
cuatro concentradores, y es de 500 m. 

Representa una mejora importante respecto a los estandares 
anteriores, puesto que se centralizan en un solo punto la ges- 
tion y la monitorizacion del estado de toda la LAN. Asimismo, 
con las topologlas en bus, el mal funcionamiento de una esta- 
cion podia comportar el bloqueo de toda la red. Con 1 OBaseT, 
una mala conexion de un terminal es detectada por el concen- 
trador, que simplemente la desconecta e indica que el enlace 
a la estacion esta cortado o inactivo (con una luz roja, por 
ejemplo). 

• lOBaseF: similar a 1 OBaseT; sin embargo, en lugar de par 
trenzado, utiliza fibra optica (generalmente, multimodo), con 
que se consigue un alcance mucho mayor (hasta 2 km). 



• 100BaseT y lOOBaseF: similares a 1 OBaseT y lOBaseF, respec- 
tivamente; sin embargo, funcionan a 100 Mbps. A causa del 
protocolo de control de acceso al medio CSMA/CD, el alcance 
se reduce mucho (1 00 m entre estacion y concentrador, sin po- 
sibilidad de encadenar concentradores). 



• Gigabit Ethernet: las variantes mas comunes son lOOOBaseT, 
sobre cableado de cobre categorla 5 (equivalente al necesario 
para 1 OOBaseT) y 1 OOOBaseSX, sobre fibra. Tiene el mismo al- 
cance que 100BaseT, 100 m. 

• 1 0 Gigabit Ethernet: actualizacion de Ethernet para el siglo XXI 
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11.3.3. Direcciones LAN 



Las direcciones LAN estan divididas en diferentes campos, como 
puede observarse en la figura siguiente: 



Figura 53. 




a) Formato de direccidn MAC universal 
0 23 I 24 



b) Formato de direccion multicast 




0 


47 1 



La mitad menos significativa de la direccion (los bits del 2 al 23), 
asignada por el IEEE a cada fabricante de manera fija, es el OUI 
[organizational unique identifier). Este ultimo, cuando fabrica las 
tarjetas, programa (en ROM) la direccion completa, que esta for- 
mada por el OUI mas una parte variable que el mismo fabricante 
asigna individualmente para cada tarjeta: la OUA [organizational 
unique address ). 



Nota 



No es del todo cierto que el 
unico grupo multicast Ethernet 
relevante sea el broadcast. La 
red Internet dispone del proto- 
colo IGMP ( Internet group 
multicast protocol), que tam- 
bien trabaja sobre tramas 
Ethernet multicast. 



Existen dos bits del OUI que siempre son cero cuando se trata de 
la direccion de origen: el bit multicast (M) y el bit local (L). Este ul- 
timo no se utiliza casi nunca y, portanto, lo consideraremos siem- 
pre cero. 

Tanto la direccion de destino como la de origen de la trama tienen 
el mismo formato, con la unica diferencia de que la direccion de 
destino tambien puede ser de tipo multicast (bit M = 1 ). En este caso, 
el numero que lleva no se refiere a una estacion en particular, sino 
que se dirige a un grupo de estaciones. Cada una de las cuales co- 
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noce el grupo o grupos a los que esta adscrita. Por norma general, 
cada uno de los grupos se refiere a grupos de estaciones que com- 
parten una misma aplicacion o un mismo protocolo. En el IP, el uni- 
co grupo multicast Ethernet relevante es el broadcast. 

Sobre papel, las direcciones LAN se escriben en hexadecimal, sepa- 
rando los bytes con dos puntos y escribiendo primero el byte menos 
significativo, por ejemplo: 

08:00:00:10:97:00 

El primer byte (que es el menos significativo) es siempre divisible por 
cuatro en direcciones no multicast que tienen los bits M y L a 0. 

El grupo broadcast es especial, en el sentido de que, por defecto, to- 
das las estaciones le pertenecen; portanto, es una manera de difun- 
dir informacion simultaneamente a todas las estaciones. El concepto 
de broadcast no es exclusivo de Ethernet, sino que es comun a mu- 
chos otros protocolos de LAN y WAN (tambien en el IP). Ponertodos 
los bits de la direccion a 1 constituye la manera mas habitual de re- 
presentor la direccion broadcast, y es la que utilizan las LAN 
(FF:FF:FF:FF:FF:FF). 
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12. Protocolos del nivel de trcmsporte 



El objetivo principal del nivel de transporte es establecer una comunica- 
cion extremo a extremo a traves de una red. En otras palabras, actuar 
de interfaz entre los niveles orientados a la aplicacion y los niveles orien- 
tados a la red de la jerarqufa de protocolos (tanto OSI como TCP/IP). 

El nivel de transporte oculta a los niveles altos del sistema el tipo de tec- 
nologfa (red) al que esta conectado el terminal. La figura siguiente des- 
cribe el posicionamiento del nivel de transporte respecto al resto de los 
niveles: 




En este apartado nos interesan los dos protocolos del nivel de trans- 
porte que se definen en la pila TCP/IP: UDP y TCP. UDP es no orien- 
tado a la conexion, mientras que TCP es orientado a la conexion. 

En el nivel de transporte se definen dos direcciones que lo relacionan 
con los niveles superior e inferior: 

• La direccion IP, que ya conocemos, es la direccion que identifica 
un subsistema dentro de una red. 

• El puerto identifica la aplicacion que requiere la comunicacion. 
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Para identificar las diferentes aplicaciones, los protocolos TCP/IP 
marcan cada paquete (o unidad de informacion) con un identificador 
de 1 6 bits llamado puerto. 

La verdadera utilidad de los puertos es que permiten multiplexor 
aplicaciones sobre protocolos del nivel de transporte. Elio signi- 
fica que un mismo protocolo de transporte Neva informacion de 
diferentes aplicaciones y estas ultimas son identificadas por el 
puerto. 

Si alguna aplicacion que corre en un terminal quiere establecer una 
comunicacion con un servidor o con otro terminal, debe utilizar un 
protocolo de transporte: el TCP o el UDP. Como el destino puede 
encontrarse en una red remota, los protocolos de transporte nece- 
sitan el protocolo Internet para poder llegar al terminal o servidor 
remoto. 



Cuando se establece la comunicacion, no solo es esen- 
cial conocer el puerto que identifica la aplicacion de 
destino, sino tambien la direccion IP que identifica el 
terminal o servidor dentro del conjunto de redes. 




Fluio 
de byte* 

Puerto 



Figura 55. 



Relacibn entre niveles en la jerarqufa de protocolos TCP/IP 



Segmento TCP 
/Datagramo UDP 

Tipo de protocolo 
de transporte 



Dalagrama IP 



Direccion IP 
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Como podeis observar en la figura anterior, las aplicaciones utilizan 
uno de los dos protocolos de transporte para comunicarse con equi- 
pos remotos. Para que un protocolo de aplicacion se pueda comuni- 
car con otro del mismo nivel situado en un terminal remoto, debe 
transmitirle un flujo de bytes que es encapsulado por los protocolos 
del nivel de transporte. 



El conjunto de bytes que transmite el nivel de transporte 
TCP se conoce como segmenfo TCP, mientras que el 
conjunto de bytes que transmite el protocolo de trans- 
porte UDP se llama datagrama UDP. 



En general, dos aplicaciones se comunican siguiendo el modelo 
cliente/servidor. En una conexion es tipico que una aplicacion (el 
cliente) inicie una comunicacion pidiendo una informacion a otra 
aplicacion (el servidor). Pensemos en un ordenador que este conec- 
tado a una LAN y tenga asignada una direccion IP. Supongamos 
que dicho ordenador actua como servidor de correo electronico, 
ademas de como servidor de nombres. Un cliente conectado a Inter- 
net que solicita resolver un nombre necesita conocer la direccion IP 
asignada a este ordenador y el puerto que identifica la aplicacion 
servidor que resuelve nombres. 



Nota 



Veremos el modelo cliente/ 
servidor en la unidad 15. 



El cliente necesita conocer ambas direcciones puesto que el servidor 
estara conectado a una red y, portanto, tendra una direccion IP que 
debe ser conocida para que se pueda establecer una comunicacion 
con esta maquina remota. Dicha comunicacion se consigue por 
medio del IP. Sin embargo, una vez conseguida, el servidor debe 
ser capaz de identificar la aplicacion con que desea comunicarse el 
cliente entre las muchas que corren: servidor de nombres, servidor 
de correo electronico, etc. 

El cliente conoce la direccion IP de origen (la suya), la direccion IP de 
destino (la del servidor) y su puerto de origen (identifica la aplicacion 
cliente). Sin embargo, tambien debe conocer el numero (puerto de 
destino) que identifica la aplicacion deseada en el servidor, y lo hace 
por medio de los llamados puertos conocidos ( well-known port). 
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Jn puerto conocido (well-known port) es un puerto 
(numero) reservado que identifica una aplicacion cono- 
cida. Estos puertos son asignados por IANA (Internet 
Assigned Numbers Authority) 



Ejemplo 

Los valores de puertos conocidos para aplicaciones 

que utilizan el UDP son los siguientes: 

• Puerto 7 para el servidor de eco. 

• Puerto 53 para el servidor de nombres (DNS, domain 
name server). 

• Puerto 69 para el protocolo de transferencia de fi- 
cheros trivial (TFTP, trivial file transfer protocol ). 

Y algunos valores de puertos conocidos para aplicacio- 
nes que utilizan el TCP son los siguientes: 

• Puertos 20 y 21 para el protocolo de transferencia 
de ficheros, FTP de datos y de control respectiva- 
mente. 

• Puerto 23 para el Telnet Remote Login. 

• Puerto 80 para el HTTP. 



Evidentemente, el servidor no necesita conocer a priori el puerto de 
origen, puesto que se limita a responder a cualquier peticion de cual- 
quier cliente. Este ultimo informa en la unidad de datos de protocolo 
(PDU) del nivel de transporte (o bien un datagrama UDP, o bien un 
segmento TCP) de los puertos de origen y de destino, de manera que 
el servidor conocera el puerto de origen una vez haya recibido una 
peticion. 
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1 3. El UDP ( user datagram protocol ) 



El UDP es un protocolo no orientado a la conexion, de manera que 
no proporciona ningun tipo de control de errores ni de f I u jo, aunque 
utiliza mecanismos de deteccion de errores. En caso de detector un 
error, el UDP no entrega el datagrama a la aplicacion, sino que lo 
descarta. Conviene recordar que, por debajo, el UDP esta utilizando 
el IP, que tambien es un protocolo no orientado a la conexion. Las 
caracteristicas mas importantes del UDP son las siguientes: 



Nota 



El UDP es un protocolo no 
orientado a la conexion. 
Elio significa que cada da- 
tagrama UDP existe con in- 
dependence del resto de 
los datagramas UDP. 



• No garantiza la fiabilidad; es decir, no ofrece la seguridad de que 
cada datagrama UDPtransmitido llegue a su destino; es un protoco- 
lo best-effort: el UDP hace todo lo posible para transferir los datagra- 
mas de su aplicacion, pero no garantiza su entrega. 

• No preserva la secuencia de la informacion que le proporciona la 
aplicacion. Como esta en modo datagrama y utiliza un protocolo 
por debajo como el IP, que tambien esta en modo datagrama, la 
aplicacion puede recibir la informacion desordenada. La aplicacion 
debe estar preparada para que haya datagramas que se pierdan, 
lleguen con retardo o se hayan desordenado. 



Figura 56. 
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La figura anterior muestra la unidad de datos del protocolo UDP y su 
encapsulamiento en un paquete IP. Cada operacion de salida de un 
datagrama UDP provoca la generacion de un paquete IP. 



El datagrama UDP consta de una cabecera y un cuerpo para encap- 
sular los datos. La cabecera consta de los elementos siguientes: 



Nota 



Hay muchas aplicaciones 
que limitan la medida de 
sus buffers de transmision y 
recepcion por debajo de la 
medida maxima de un da- 
tagrama UDP. Por ejemplo, 
es tipico encontrar aplica- 
ciones que proporcionan, 
por defecto, medidas maxi- 
mas del datagrama UDP de 
8.192 bytes. Este valor pro- 
viene de la cantidad de da- 
tos del usuario que el NFS 
( network file system ) puede 
leer o escribir por defecto. 



Los campos Puerto de origen y Puerto de destino, que identifi- 
can las aplicaciones en los terminales de origen y de destino. 
Cada puerto tiene 16 bits. 



El campo Longitud indica la longitud, en bytes, del datagrama 
UDP incluyendo la cabecera UDP (es la diferencia de la longitud 
del datagrama IP menos la cabecera IP). Como la longitud maxi- 
ma de un datagrama IP es de 65.535 bytes, con una cabecera es- 
tandar de 20 bytes, la longitud maxima de un datagrama UDP es 
de 65.51 5 bytes. 

El campo Checksum (16 bits) es opcional y protege tanto la ca- 
becera como los datos UDP (es preciso recordar que el checksum 
del datagrama IP solo cubre la cabecera IP). Cuando el UDP re- 
cibe un datagrama y determina que hay errores, lo descarta y no 
lo entrega a ninguna aplicacion. 



Nota 

El calculo del checksum en el UDP es muy parecido al 
calculo del checksum en el IP (suma en complemento 
a 1 de palabras de 16 bits), con la particularidad de 
que la longitud del datagrama UDP puede ser par o 
impar. En caso de que sea impar, se le ahade un 0 al 
final del datagrama para calcular el checksum (este 0 
no se transmite). Para calcular elchecksum , el UDP uti - 
liza una seudocabecera de 12 bytes con algunos de 
los campos IP. Esta ultima no se transmite; el UDP solo 
la utiliza para calcular el checksum y le sirve para com- 
probar que la informacion que le proporciona el IP sea 
realmente para el. 
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Si el UDP no aporta nada a IP, se podrfa pensar que su 
presencia es superflua. Pero no es asf, porque no es es- 
trictamente cierto que no aporte nada. Aporta la multi- 
plexacion de aplicaciones sobre la misma comunicacion 
de red, a traves del concepto de puerto. 



Las aplicaciones que no requeiren de la funcionalidad del TCP, usan 
el UDP como protocolo de trasporte. Podemos poner dos ejemplos 
de estas aplicaciones: 

• Aplicaciones en tiempo real. Estas aplicaciones requieren poco re- 
tardo (mejor dicho, poca variabilidad en el retardo), y TCP puede 
introducir retardos considerables si tiene que esperar, por ejem- 
plo que le llegue un paquete que se ha perdido. 

• Aplicaciones interesadas en transmitir informacion en modo 
multicast o broadcast (a un grupo de usuarios o a todos los de 
una red). En este caso, no tiene sentido establecer una conexion 
como hace el TCP con cada una de las estaciones destino. 
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14. El TCP ( transmission control protocol ) 



Como hemos podido observar, el UDP no garantiza la entrega de la 
informacion que le proporciona una aplicacion. Tampoco reordena 
la informacion en caso de que llegue en un orden diferente de aquel 
en que se ha transmitido. Existen aplicaciones que no pueden tolerar 
dichas limitaciones. Para superarias, el nivel detransporte proporcio- 
na un protocolo llamado TCP. 



El TCP proporciona fiabilidad a la aplicacion; es decir, garantiza la 
entrega de toda la informacion en el mismo orden en que ha sido 
transmitida por la aplicacion de origen. Para conseguir esta fiabili- 
dad, el TCP proporciona un servicio orientado a la conexion con un 
control de flujo y errores. 



14.1. El TCP proporciona fiabilidad 



Para proporcionar un servicio fiable a la aplicacion, el TCP se basa 
en los principios siguientes: 



1) Transmision libre de error. El TCP debe entregar a la aplica- 
cion de destino exactamente la misma informacion que le en- 
trego la aplicacion de origen. De hecho, se trata de una 
entrega "casi libre" de errores, puesto que puede haber algu- 
nos que un mecanismo de deteccion de errores no pueda de- 
tector. 



2) Garantfa de entrega de la informacion. El TCP garantiza que 
toda la informacion transmitida por la aplicacion de origen se 
entregue a la aplicacion de destino. Si no es posible, el TCP 
debe avisar a la aplicacion. 
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3) Garantfa de mantenimiento de la secuencia de transmision. 

El TCP garantiza la entrega del flujo de informacion en el mis- 
mo orden en que le fue entregado por la aplicacion de origen. 



4) Eliminacion de duplicados. El TCP garantiza que solo entregara 
una copia de la informacion transmitida a la aplicacion de desti- 
no. En caso de que reciba copias a causa del funcionamiento de 
la red o de los protocolos que se implementan por debajo del ni- 
vel de transporte, el TCP las eliminara. 



La fiabilidad de la transmision que proporciona TCP se consigue gra- 
cias a las siguientes estrategias: 



• El TCP esta orientado a la conexion: tiene una fase de estable- 
cimiento de la conexion, una de transmision de datos y una de 
desconexion. 

• El TCP utiliza el concepto buffered transfer: cuando se transfiere 
informacion, el TCP divide los flujos de datos ( byte stream ) que 
le pasa la aplicacion en segmentos del tamano que le conven- 
ga. El TCP decide el tamano de los segmentos tanto si la apli- 
cacion genera un byte de informacion, como si genera flujos 
de grandes dimensiones. En el primer caso, el TCP puede es- 
perar a que la memoria intermedia se llene mas antes de trans- 
fer^ la informacion, o bien la puede transferir de inmediato 
(mecanismo push). En caso de que los flujos sean muy grandes, 
el TCP puede dividir la informacion en tamanos mas pequenos 
antes de transferirlos. 



• El TCP utiliza una conexion full duplex: la transferencia de in- 
formacion es en ambos sentidos. La aplicacion ve dos flujos in- 
dependientes. En caso de que la aplicacion cierre uno de los 
flujos, la conexion pasa a ser half duplex . Elio significa que uno 
de los extremos (el que no ha cerrado la conexion) puede con- 
tinuar enviando informacion por el canal, mientras que el otro 
extremo (el que ha cerrado la conexion) se limita a reconocer 
la informacion. No obstante, no es normal encontrar este caso. 
Lo mas habitual es que, si un extremo cierra la conexion, el 
otro tambien la cierre. 
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14.2. Formato del segmento TCP 



La unidad de informacion del protocolo TCP se llama segmento TCP 
y su formato el siguiente: 



Figura 57. 




El segmento TCP consta de una cabecera y un cuerpo para encapsu- 
lar datos. La cabecera consta de los campos siguientes: 



a) El campo Puerto de origen identifica la aplicacion en el terminal 
de origen. 



Figura 58. 
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b) El campo Puerto de destinoidentifica la aplicacion en el terminal 
de destino. 



Figura 59. 







Puerto de destino: 16 bits 



c) El campo Numero de secuencia identifica el primer byte del cam- 
po de datos. En el TCP no se numeran segmentos, sino bytes. Por 
tanto, el numero de secuencia identifica el primer byte de los datos 
que envia el segmento: al principio de la conexion se asigna un nu- 
mero de secuencia inicial (ISN, del ingles initial sequence number), 
a partir del cual el TCP numera los bytes consecutivamente. 



Figura 60. 




d) El campo Numero ACK. El TCP reconoce datos por medio de la 
tecnica de piggybacking . Al activar un bit de la cabecera (el bit 
ACK), el TCP tiene en cuenta el numero de secuencia ACK que in- 
dica al otro extremo TCP el proximo byte que esta dispuesto a re- 
cibir. Dicho de otra manera, el numero ACK menos uno indica el 
ultimo byte reconocido. 



Figura 61 . 
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e) El campo Longitud de la cabecera indica la longitud de la cabe- 
cera, que puede ser variable. La longitud tipica es de 20 bytes; sin 
embargo, si el TCP utiliza el campo de opciones, puede llegar a 
una longitud maxima de 60 bytes. De este modo, el TCP sabe 
donde empiezan los datos. 



Figura 62. 




f) El campo Reservado, tal como su nombre indica, esta reservado 
y se inicializa con ceros. 



Figura 63. 




g) El campo Control esta formado por seis indicadores indepen- 
dientes, cada uno de los cuales senala una funcion especffica del 
protocolo cuando esta activo (a 1): 



Figura 64. 




• URG: indica que hay datos urgentes (y el campo Urgent pointer 
indica la cantidad de datos urgentes existentes en el segmento). 
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• ACK: cuando este bit esta activo, el campo Numero ACK indica el 
byte siguiente que espera recibir la conexion TCP. Si este bit no 
esta activo, el campo Numero ACK no tiene ningun significado 
para el TCP. 



Nota 



No debe confundirse PSH 
con el indicador URG, que 
indica que la aplicacion ha 
senalado una porcion del 
segmento como urgente. 



PSH: invoca la funcion push en el protocolo. Esta funcion dice al 
receptor que entregue a la aplicacion todos los datos que tenga 
disponibles en la memoria intermedia de recepcion sin esperar 
a completarlos con datos adicionales. De este modo, los datos 
no esperan en la memoria intermedia receptora hasta completar 
un segmento de dimension maxima. 



• RST: realiza un reset de la conexion. 



• SYN: se utiliza para iniciar una conexion y tambien sirve para re- 
sincronizar los numeros de secuencia. 



• FIN: ind ica que el transmisor ha acabado la conexion. 



h) El campo Ventana indica cuantos bytes componen la ventana de 
transmision del protocolo de control de flujo por ventana desli- 
zante. A diferencia de los protocolos del nivel de enlace, en que 
la ventana era constante y contaba tramas, en el TCP la ventana 
es variable y cuenta bytes. Con cada segmento transmitido, un ex- 
tremo TCP advierte al otro extremo de la cantidad de datos que 
esta dispuesto a recibir en cada momento. De este modo, el ex- 
tremo que recibe un segmento actualiza el tamano de su ventana 
de transmision. 



Figura 65. 







Ventana: 16 bits 
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i) El campo Checksum se utiliza para detector errores. 



Figura 66. 




j) El campo Urgent pointer tiene sentido cuando el bit de control 
URG esta activo. Indica que los datos que envia el origen son ur- 
gentes e identifica el ultimo byte de dicho campo. La aplicacion es 
la que indica que estos ultimos son urgentes y lo sabe porque el 
TCP se lo indica en la recepcion. 



Figura 67. 
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Urgent pointer : 1 6 bits 



Ejemplo 



Si el numero de secuencia 
indica 1 .000 y el urgent po- 
inter indica 200, significa 
que los bytes del 1 .000 al 
1 .200 se consideran urgen- 
tes. A partir del byte 1 .20 1 
los datos se vuelven a consi- 
derar normales. 



No fa 

Algunas aplicaciones que utilizan el Urgent pointer 
son, por ejemplo telnet, rlogino ftp. En la libre- 
rfa de sockets, el trafico urgente se denomina trafico 
fuera de banda (out of band). 

k) El campo Opciones TCP permite anadir compos a la cabecera 
para realizar las operaciones siguientes: 



Figura 68. 
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Nota 



El tamano maximo del seg- 
mento TCP transmitido se 
especifica durante el esta- 
blecimiento de la conexion y 
define la maxima longitud 
de datos que enviara el 
TCP. 



• Marcar el tiempo ( timestamp ) en que se transmitio el segmento y 
de este modo poder monitorizar los retardos que experimentan 
los segmentos desde el origen hasta el destino. 

• Aumentar el tamano de la ventana. 

• Indicar el tamano maximo del segmento (MSS, del ingles maxi- 
mum segment size ) que el origen esta preparado para recibir. 
Por tanto, el receptor no le puede transmitir segmentos por en- 
cima de este valor. 



Actividad 

2Cual es el tamano de un datagrama IP en funcion de 
MSS? 

Solucion 

Si el tamano de los datos TCP es MSS, sera preciso ana- 
dirle 20 bytes de la cabecera TCP mas 20 bytes de la ca- 
becera IP (teniendo en cuenta las cabeceras basicas sin 
opciones). Elio significa que la longitud del datagrama IP 
sera de MSS + 40 bytes (siempre asumiendo que tanto el 
TCP como el IP no utilizan sus campos de opciones). 

Si no se especifica el tamano maximo durante la transmi- 
sion del segmento SYN, se toman por defecto 536 bytes 
(el tamano por defecto de un datagrama IP es de 576 
bytes, menos los 40 bytes de las cabeceras IP y TCP). 



Nota 



Consultad la MTU en el 
apartado 1 1 .1 .2. 



El hecho de elegir el MSS no es trivial. En general, cuanto mayor sea 
el MSS, mejor, puesto que las cabeceras IP y TCP se amortizan mas. 
Sin embargo, si la MTU es pequena, sera preciso fragmentar el da- 
tagrama IP (es decir, el segmento TCP); portanto, por norma general 
no interesa elegir MSS mayores que la MTU. En este caso, existen di- 
ferentes posibilidades: 



1 ) Buscar la MTU local de la red a que esta conectada la estacion y, 
si hay MTU mas pequenas hasta el destino, habra fragmentacion. 

2) Utilizar MTU discocvery path, un mecanismo de busqueda para ave- 
riguar cual es la MTU menor desde el origen hasta el destino y utilizar 
como MSS esta ultima menos los 40 bytes de cabeceras IP y TCP. 
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14.3. Establecimiento de la conexion 

Para establecer una conexion, el TCP utiliza el protocolo three-way 
handshake. Este ultimo necesita tres segmentos TCP para poder es- 
tablecer la conexion. 



Consideremos que el servidor esta en un estado de escucha, llamado 
listen, y que el cliente quiere establecer una conexion con el servidor. 
El TCP de la maquina cliente iniciara la peticion de conexion TCP, 
que sera contestada por el TCP de la maquina servidor. 



Figura 69. 



Cliente 







Servidor 
en estado 
de escucha 



SYN (J) 



1 ) Segmento de 

peticion de conexidn I 



2) Segmento de SYN (fc), ACK (k + 1) 

conrirmacidn 4 

de conexi6n 



ACK (k + 1) 



3) Segmento de 
reconocimiento 



Para que el cliente TCP pueda establecer una conexion TCP con el 
servidor, se siguen los pasos siguientes: 

1) Peticion de la conexion 

El TCP cliente envia un segmento de peticion de conexion al servidor. 
Dicho segmento, que se conoce como segmento SYN porque tiene 
activado el bit SYN en el campo Control de la cabecera del segmento 
TCP, especifica el numero de secuencia inicial TCP del cliente (ISN). 



Nota 



El segmento SYN especifica 
mas parametros, tales como 
el puerto del servidor al que 
se quiere conectar el cliente, y 
suele especificar tambien la 
medida maxima del segmen- 
to (MSS) que el cliente trans- 
mitira. 



El numero de secuencia inicial se elige al azar. La razon es muy sen- 
cilla. Hay paquetes que pueden sobrevivir en la red una vez se ha ce- 
rrado la conexion TCP (incluso si ha sido a causa de una cafda del 
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sistema). Es preciso asegurarse de que una conexion nueva elige un 
numero de secuencia inicial que no exista. El TCP recomienda utilizar 
un numero de secuencia inicial basado en una variable que se incre- 
menta una cantidad x cada y tiempo (por ejemplo, en 4.4BSD hay 
un contador que se incrementa cada 8 ms). 

Si el sistema cae, pasados unos segundos vuelve a estar en funcio- 
namiento e inmediatamente se establece una conexion nueva utili- 
zando el mismo puerto y la misma direccion IP, se podrfa interpretar 
que los segmentos TCP que han quedado retrasados en la red y que 
ya existfan con anterioridad a la cafda de la maquina, pertenecen a 
la conexion nueva, lo que provocarfa la confusion y el mal funciona- 
miento de dicha conexion. Elio sucederia incluso con independencia 
del numero de secuencia inicial elegido. 

Con el objetivo de protegerse de esta situacion, se combinan dos tec- 
nicas: una consiste en elegir el numero de secuencia inicial de ma- 
nera aleatoria y la otra es el denominado quiet time, que consiste en 
que el TCP no crea ninguna conexion nueva despues de un rebote de 
maquinas hasta que no transcurre un tiempo determinado denomi- 
nado MSL (del ingles maximum segment lifetime: "tiempo maximo de 
vida de un segmento"). De este modo, se asegura de que no recibira 
segmentos antiguos de otras conexiones. 



Not a 

El MSL depende de la implementacion; sin embargo, 
los valores normales son, aproximadamente, de 30 
segundos, 1 minuto 6 2 minutos. No obstante, existen 
muchas implementaciones que no tienen en cuenta 
esta situacion, puesto que consideran que un rebote 
de maquinas dura mas tiempo que el MSL. 



2) Confirmacion de la conexion 

El servidor responde a la peticion de establecimiento de la conexion con 
un segmento SYN que indica el numero de secuencia inicial que utilizara. 

Asimismo, este segmento contiene un reconocimiento (ACK) del seg- 
mento SYN del cliente que indica el ISN del cliente mas 1 (el numero 
de secuencia inicial del cliente mas 1). 
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Nota 



Conviene recordar que el TCP numera los ACK con el 
numero de secuencia del proximo byte que espera re- 
cibir (en este caso, el servidor espera que el proximo 
byte enviado por el cliente sea J + 1). En la figura an- 
terior, serfa el segmento SYN (K), ACK ( J + 1), donde 
K es el ISN elegido por el TCP servidor. 



3) Reconocimiento de la conexion 



El cliente reconoce el segmento SYN (K) del servidor con un recono- 
cimiento que contiene el ISN servidor mas 1 . En la figura anterior, se- 
rfa el segmento ACK (K + 1). 



Se dice que quien envfa el primer segmento SYN (en este caso, el 
cliente) efectua una apertura activa ( active open), mientras que quien 
recibe el primer segmento SYN y envfa el proximo segmento SYN (en 
este caso, el servidor) lleva a cabo una apertura pasiva (passive 
open). 

Puede darse el caso de que ambos extremos efectuen una apertura 
activa en el mismo momento. Esta situacion se denomina apertura si- 
multanea ( simultaneous open). 

Despues de estos tres pasos, podemos decir que ya se ha estable- 
cido la conexion entre el cliente y el servidor. 



Nota 


Nota 


Utilizaremos el programa tcpdump para ver como 
funciona el protocolo de establecimiento de una co- 


En el anexo 2 podeis encon- 
trar una descripcion del pro- 
grama tcpdump. 


nexion. 




Asumimos que nos hemos conectado a una maqui- 
na llamada argos y hacemos un rlogin a la ma- 
quina helios 





argos % rlogin helios 



145 




Las primeras Ifneas que obtenemos con el tcpdump son las si- 

guientes: 

• 15:56:54.796091 argos.1023 > helios . login : S 3541904332: 3541904332 
(0) win 31744 <mss 1460> 

• 15:56:54.796091 helios. login > argos.1023: S 548133143: 548133143 

(0) ack 33541904333 win 8760 <mss 1460> 

• 15:56:54.796091 argos.1023 > helios . login : . ack 548133144 win 31744 

Interpretacion 

1) argos, desde el puerto 1.023, envfa a helios una 
peticion de conexion por medio de un segmento 
SYN. El numero de secuencia inicial (ISN) elegido 
por argos es el 3.541.904.332, y argos anuncia 
que puede recibir 31.744 bytes sin reconocerlos y 
que espera recibir segmentos con un tamano maxi- 
mo de 1 .460 bytes. 

2) helios responde con un segmento SYN eligiendo 
como ISN el numero 548.1 33.1 43 y responde con un 
ACK con el byte siguiente que espera recibir deargos, 
el 3.541.904.333 (3.541.904.332 + 1). Anuncia 
que puede recibir 8.760 bytes y que espera recibir 
segmentos con un tamano maximo de 1 .460 bytes. 

3) argos reconoce el segmento SYN con un segmento 
en el que espera recibir el byte 548.133.144 
(548.133.143 + 1), argos vuelve a advertir que 
esta dispuesto a recibir hasta 31.744 bytes. 



A continuacion, empezaria el intercambio de informacion entre el 
cliente y el servidor (por ejempo peticiones de login , contrasena, 
prompt de la maquina, etc.). 



Actividad 

Utilizad el programa tcpdump para ver el estableci- 
miento de una conexion. Con esta finalidad, estable- 
ced una conexion con aplicaciones diferentes (telnet, 
ftp, rlogin, etc.) y monitorizad la conexion. Obser- 
vad los segmentos de inicio de la conexion, el valor del 
numero de secuencia inicial, el del numero ACK inicial 
y el tamano de la ventana. 
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| 14.4. Terminacion de la conexion 

Cuando la transferencia de la informacion ha finalizado, el TCP dis- 
pone de un protocolo de terminacion de la conexion para cerrarla. 

En una conexion TCP full duplex, en la que los datos fluyen en ambos 
sentidos, independientes el uno del otro, cualquier conexion debe ce- 
rrarse independientemente. 

Es preciso tener en cuenta que tanto el cliente como el servidor pue- 
den cerrar la conexion. Sin embargo, la situacion normal es que la 
aplicacion cliente inicie la peticion de conexion y tenga, posiblemen- 
te, un usuario interactive que le pida su cierre por medio, por ejem- 
plo, de una instruccion, que en telnet serfa logout y en un ftp seria 
bye. Por tanto, supongamos que es el cliente quien pide cerrar la co- 
nexion (si fuera el servidor, seria similar). Los pasos que se siguen son 
los siguientes: 

1 ) El cliente envia un segmento TCP del tipo FIN con el numero de 
secuencia correspondiente (J). Elio significa que a partir de este 
momento no habra mas datos que fluyan en este sentido (cliente 
— > servidor). 

2) El servidor envia una confirmacion del cierre por medio de un 
ACK con el numero de secuencia recibido mas 1 (J + 1). 

El TCP servidor indica a su aplicacion que el cliente cierra la conexion. 
La aplicacion servidor indica a su TCP que la cierre a continuacion. 

3) El servidor envia un segmento TCP del tipo FIN al cliente con el 
numero de secuencia correspondiente (K). 

4) El TCP cliente responde automaticamente con un ACK (K + 1). 



Se dice que quien envia el primer segmento FIN (en 
este caso el cliente) I leva a cabo un cierre activo ( active 
close), mientras que quien lo recibe (en este caso el 
servidor) realiza un cierre pasivo (passive close). 



Nota 



El segmento FIN recibe este 
nombre porque tiene acti- 
vado el bit FIN en el campo 
Control de la cabecera del 
segmento TCP. 
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La conexion que efectua el cierre activo entra en un estado denomi- 
nado TIME_WAIT, de manera que debera esperar un tiempo (por 
norma general, una o dos veces el MSL) antes de utilizar de nuevo el 
mismo puerto. Lo mas habitual es que sea el cliente quien efectue el 
cierre activo. Como los clientes suelen utilizar puertos locales effme- 
ros, este tiempo de espera no les afecta. En cambio, si es el servidor 
quien efectua el cierre activo, podemos encontrarnos con que no se 
pueda reinicializar durante 1 6 2 minutos. Elio sucede porque el ser- 
vidor utiliza puertos conocidos que no se pueden volver a reasignar 
hasta que no acabe el procedimiento quiet time y se saiga del estado 
TIME WAIT. 



Lectura complementaria 



Podeis encontrar una sec- 
cion dedicada a este tema 
en el libro: 

W.R. Stevens (1998). 
TCP/IP Illustrated (vol. 1: 
"The Protocols", cap. 19, 
pag. 252). Wilmington: 
Addison-Wesley, 1994. 



Es posible que solo cierre la conexion (salida de datos) uno de los ex- 
tremos, mientras que el otro (recepcion) se mantiene abierfo. Esta situa- 
cion se denomina half-close, pero hay pocas aplicaciones que se 
aprovechen de el la . Lo mas normal es que ambas aplicaciones cie- 
rren sus canales de comunicaciones. Asimismo, puede darse el caso 
de que dos extremos efectuen un cierre activo. Esta situacion se de- 
nomina cierre simultaneo ( simultaneous close). 

Monitorizacion de la terminacion de una conexion utilizando el 
programa tcpdump 



Utilizaremos el comando tcpdump para ver como funciona el pro- 
tocolo de terminacion de la conexion. Asumimos que en el rlogin del 
ejemplo de establecimiento de la conexion Helios hace un logout 
(pide el cierre de la conexion). 



helios % logout 

Las Ifneas que obtenemos con el tcpdump son las siguientes: 

15:57:01.616091 helios. login > argos.1023: F 1417: 1417 (0) 
ack 41 win 8760 

15:57:01.616091 argos.1023 > helios . login : .ack 1418 win 

31744 

15:57:01.616091 argos.1023 > helis. login: F 41:41 (0) ack 

580 31744 

15:57:01.616091 helios. login > argos.1023: .ack 42 win 8760 
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Interpretation 

1 ) Helios envfa un segmento con el indicador F (FIN). 
El numero de secuencia es el 1 .41 7 y envfa 0 bytes 
de datos. Espera recibir el byte 41 de argos y ad- 
vierte una ventana de 8.760 bytes. 

2) argos envfa un reconocimiento por medio de un 
segmento con ACK 1.418 (1.417 + 1) y advierte 
una ventana de 31 .744 bytes. 

3) Ahora le toca a argos cerrar su conexion TCP. Con 
esta finalidad, envfa un segmento con el indicador 
F (FIN) a Helios. El numero de secuencia es el 41 (es 
el que esperara Helios ) y envfa 0 bytes de datos. 
Advierte una ventana de 31 .744 bytes. 

4) Helios recibe el segmento, lo reconoce con el ACK 
numerado como 42 (41 + 1 ) y advierte una venta- 
na de 8.760 bytes. 

Helios ha efectuado un cierre activo, mientras que argos 

ha efectuado un cierre pasivo. 



Nota 



La notacion de los numeros 
de secuencia y numeros 
ACK se establece a partir 
del ISN; es decir un numero 
de secuencia 1.417 indica 
un numero de secuencia 
ISN + 1.417. 



Actividad 

Utilizad el programa tcpdump para ver el cierre de una 
conexion. Con esta finalidad, estableced una conexion 
con diferentes aplicaciones (telnet, rlogin, etc.) y su- 
pervisadla. 



14.5. Diagrama de estados del TCP 



En el diagrama de estados del TCP se describen los diferentes esta- 
dos por los que pasa una conexion desde su establecimiento hasta 
su terminacion, incluyendo la etapa de transferencia de la informa- 
cion. Los nombres de los estados TCP son los mismos que se pueden 
consultar con la llamada al sistema netstat. 



Lectura complementaria 



W.R. Stevens (1998). "The 
Protocols" TCP/IP Illustrated 
(vol. 1 ). Wilmington: 
Addison-Wesley, 1994. 



El estado ESTABLISHED se corresponde con la transferencia de la in- 
formacion. El resto de los estados se corresponden con el estableci- 
miento y la terminacion de la conexion, teniendo en cuenta todas las 
maneras posibles de establecer y cerrar una conexion en el TCP. Los 
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sfmbolos SYN, RST, FIN y ACK se corresponden con los bits de indi- 
cacion de la cabecera TCP. 




Un ejemplo de como se interpreta este diagrama serfa el protocolo de 
terminacion de una conexion, en que ya vimos que el extremo TCP que 
pedfa el cierre efectuaba un cierre activo. Elio significa que pasaria del 
estado ESTABLISHED al estado FIN_WAIT_1 enviando un segmento 
FIN. 

Desde aquf puede pasar a uno de los tres estados que describen 
como se puede realizar un cierre activo dependiendo de como se cie- 
rre la conexion: 

• Con un cierre simultaneo (simultaneous close), pasa a CLOSING. 

• Con la recepcion de un ACK, pasa a FIN_WAIT_2, donde espera 
recibir un FIN. 

Nota 



Consultad el MSL en el apar- 
tado 1 5.3 de esta unidad. 
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Con la recepcion de un FIN y un ACK, pasa a TIME_WAIT, donde 
espera dos veces el MSL antes de liberar el puerto. 







Ya hemos visto que el extremo TCP que recibe un FIN Neva a cabo 
un cierre pasivo. Por tanto, pasa del estado ESTABLISHED al estado 
CLOSE_WAIT enviando los indicadores ACK y FIN correspondientes 
para acabar la conexion. 



La fase de establecimiento tambien se puede seguir con facilidad por 
medio del diagrama de estados, teniendo en cuenta que extremo 
efectua el cierre activo y cual lleva a cabo el cierre pasivo. 



Actividades 

• Utilizad el comando netstat para ver el estado de 
las conexiones TCP que tengais en este momento. Si 
no teneis ninguna aplicacion en la red, conectaos a 
algun servidor con la web, haced un ftp o un telnet 
a alguna maquina. 

• Suponed una interaccion entre un cliente y un servidor 
en la que el cliente hace una apertura activa y el servi- 
dor una apertura pasiva, a continuacion se intercam- 
bian un segmento de datos, con sus correspondientes 
reconocimientos, y finalizan con un cierre activo por 
parte del servidor, pasivo por parte del cliente. Dibujad 
el diagrama de tiempo que muestre el intercambio de 
segmentos, y en paralelo, los estados donde se en- 
cuentran las dos entidades en cada momento. 



14.6. Transferencia de ia informacion 



Una vez establecida la conexion, el TCP puede empezar la transfe- 
rencia de segmentos TCP en ambos sentidos. Para tansmitir informa- 
cion de manera fiable, el TCP implementa protocolos de control de 
errores y de flu jo. Los pasos que sigue el TCP para transferir la infor- 
macion son los siguientes: 

1 ) Cuando el TCP envia datos, mantiene un temporizador ( timeout ) 
hasta que recibe un reconocimiento (ACK) del receptor. Si el tem- 
porizador salta, el TCP retransmite los datos. 
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2) Cuando el TCP recibe un segmento de datos, envfa un reconoci- 
miento. Este ultimo se puede retornar retrasado (no de inmediato) 
si el TCP lo considera necesario. 

3) Si un segmento recibido es incorrecto (el checksum lo indica), el 
TCP descarta el segmento y no deberfa enviar la informacion. De 
hecho, como el TCP utiliza la tecnica de piggybacking (aprovecha 
los segmentos de datos que viajan en sentido contrario), lo que 
hace es retornar un segmento con el mismo numero de ACK que 
habfa reconocido la ultima vez. El transmisor vera un ACK con un 
numero repetido e interpretara que no le reconocen la informa- 
cion. Este numero se denomina ACK duplicado. 



En caso de que no tuviera datos para enviar en sentido contrario, el 
TCP puede enviar un segmento que no contenga informacion (con 
un campo de datos de cero bytes). Este segmento tendrfa el indicador 
ACK activado y reconocerfa los bytes pertinentes en el campo Nume- 
ro de ACK. El numero de secuencia no se habrfa incrementado, pues- 
to que no envfa datos. 



4) Si los segmentos llegan desordenados (por debajo hay el IP, que 
esta no orientado a la conexion), el TCP reordena los segmentos 
y pasa los datos (bytes) correctamente ordenados a la aplicacion. 
Si recibe segmentos duplicados, el TCP descarta las copias. 

5) Como el TCP posee una memoria limitada, debe efectuar un con- 
trol de flu jo. Con esta finalidad, cada extremo aviso de los datos 
que esta dispuesto a recibir en cada momento utilizando el cam- 
po Ventana (se trata de un mecanismo de ventana deslizante ba- 
sado en bytes que explicaremos mas adelante). 



Ejemplo 



- Datos interactivos: los 

que transmiten aplicacio- 
nes tales como telnet o 
rlogin. 

- Bulk data: los que trans- 
miten aplicaciones como 
correo electronico o ftp. 



El tipo de informacion que es preciso enviar puede dividirse en datos 
interactivos y datos de gran volumen o bulk data . La diferencia entre 
ellos radica en la cantidad de informacion que se transmite. Los da- 
tos interactivos transmiten pocos bytes de informacion (alrededor de 
10), mientras que los datos de gran volumen transmiten gran canti- 
dad de datos (ocupan la totalidad del tamano del segmento TCP). 
Conviene considerar que no es lo mismo cargar la red con paquetes 
pequenos de informacion que con paquetes grandes. El TCP puede 
aplicar en cada caso tecnicas diferentes de manera automatica, para 
aprovechar la red al maximo. 



152 




14.6.1. Transmision de datos interactivos 



En este tipo de comunicacion, es normal enviar pocos datos. En una 
aplicacion del tipo telnet, por ejemplo, un usuario cliente podrfa 
ejecutar el comando de Unix Is y obtener un listado de un directorio 
por parte del servidor. En esta transferencia de informacion intervie- 
nen pocos bytes desde el origen (cliente) hasta el destino (servidor) y 
se utilizan conjuntamente dos tecnicas para obtener un mejor apro- 
vechamiento de la red: 

• Reconocimientos retrasados. 

• Algoritmo de Nagle. 

Reconocimientos retrasados 

En este tipo de transferencia, es normal que el TCP no envte los re- 
conocimientos ACK inmediatamente despues de recibir los datos, sino 
que este un tiempo esperando a que haya datos para enviar en senti- 
do contrario. De este modo, puede utilizar la tecnica piggybacking y 
enviar el reconocimiento encapsulado en los datos que retornan al 
cliente. 

Es posible que el servidor se ahorre enviar un segmento que solo re- 
conoce, pero que no contiene datos. Es tipico que el TCP espere (uti- 
liza un temporizador) unos 200 ms por si hay datos para transmitir 
antes de enviar el ACK. Una vez ha transcurrido este tiempo, el 
TCP reconoce los datos recibidos hasta el momento con un seg- 
mento de datos, si dispone de datos para enviar en sentido con- 
trario /piggybacking ), o con un segmento sin datos (el numero de 
secuencia no varfa). En cualquiera de los dos casos, el indicador ACK 
estara activado y el numero ACK reconocera los datos pertinentes. 

Algoritmo de Nagle 

En numerosas ocasiones un cliente tiene muy pocos datos para enviar 
(por ejemplo, solo 1 byte). En este caso el TCP enviarfa un segmento 
solo con 1 byte de datos y con 20 bytes de cabecera TCP. El IP aha- 
dirfa 20 bytes mas de cabecera, lo que proporciona un total de 40 
bytes de control y 1 de datos. Si se transmiten muchos segmentos de 
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este tipo, la eficiencia es muy baja. Una solucion a esta baja eficien- 
cia de transmision es aplicar el algoritmo de Nagle. 

Utilizando el algoritmo de Nagle, una conexion TCP solo puede 
tener un segmento de tamano pequeno (pocos bytes) sin que se 
haya reconocido; es decir, solo puede haber un unico segmento 
de tamano pequeno viajando por la red (en vuelo). El resto de los 
segmentos de tamano pequeno no se pueden transmitir hasta que 
el ACK del segmento pequeno que este viajando por la red haya 
llegado. 

Asi, los segmentos que estan esperando para ser transmitidos se 
almacenan hasta que se recibe el ACK del segmento en vuelo. 
Cuando este ultimo llega, la conexion TCP puede enviar un seg- 
mento que contenga todos los datos almacenados hasta este mo- 
mento, formando un segmento mayor. 

El algoritmo de Nagle funciona cuando los retardos en la red son 
grandes; es decir, si la conexion cruza una WAN. En caso de que 
la conexion sea local, en una LAN, es dificil que se aplique este 
algoritmo a causa de la alta velocidad de la red. 



Nota 



En la libreria de sockets API, 
el indicador que desinhibe 
el algoritmo de Nagle es el 
TCP NODELAY. 



En ocasiones, es interesante desinhibir el algoritmo de Nagle, 
puesto que la aplicacion no puede esperar. El movimiento del ra- 
ton en X Windows System provoca segmentos pequenos. Estos mo- 
vimientos del raton deben entregarse sin retardos para que el 
usuario interactive no lo note. Las librerias desockets deben per- 
mitir, activando indicadores, desinhibir el algoritmo de Nagle. 



14.6.2. Transmision de datos de gran volumen. Control 
de flujo por ventana deslizante 

En las comunicaciones en que se envia una ingente cantidad de da- 
tos de gran volumen (correo electronico, transferencias FTP, etc.), 
como las memorias intermedias de recepcion se pueden llenar, es 
necesario un protocolo de ventana deslizante ( sliding window ) para 
controlar el flujo de datos, con la diferencia, respecto de los protoco- 
los del nivel de enlace, de que en el TCP la ventana de transmision 
es variable. 
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La idea es que cada extremo TCP regula la cantidad de datos que 
el otro extremo puede transmitir. Con esta finalidad, cada extremo TCP 
notifica al extremo opuesto, cada vez que envfa un segmento, la ven- 
tana que puede aceptar en este momento. El TCP opuesto actualiza 
su ventana de transmision de acuerdo con este valor. 



Mientras que el TCP transmisor marca los bytes que ha transmiti- 
do con un numero de secuencia, el TCP receptor retoma los bytes 
que recibe y los reconoce con un ACK. Los reconocimientos ACK 
especifican siempre el numero de secuencia del proximo octeto 
que el receptor espera recibir. 



En el TCP se reconocen posiciones de bytes en el flujo de 
datos hasta la ultima posicion que ha recibido correcta- 
mente, sin tener en cuenta el segmento al que pertenecen. 



El TCP solo activa un temporizador de retransmisiones que reprograma 
cuando recibe un reconocimiento o cuando salta el temporizador. Mas 
adelante veremos como el TCP programa el temporizador de retrans- 
misiones. La cabecera del segmento TCP especifica tres parametros 
esenciales en el funcionamiento del protocolo de ventana deslizante: 

• El numero de secuencia, que indica a su conexion opuesto el pri- 
mer byte de datos que contiene el segmento transmitido. 

• El numero de reconocimiento (numero ACK), que indica a su 
conexion opuesto el proximo byte que espera recibir y, por tanto, 
el ultimo byte recibido correctamente. 

• La ventana, que indica a su conexion opuesta el tamano de la 
memoria intermedia de recepcion y, por tanto, el tamano de la 
ventana que el transmisor debe utilizar. 

Actividad 

Asumimos que un extremo cliente TCP ha elegido el 
28.325 como numero de secuencia inicial (ISN), mien- 
tras que el extremo servidor TCP ha elegido como ISN 
el 12.555. sQue indica un segmento cliente TCP con 
numero de secuencia 29.201, numero ACK 12.655 y 
ventana 1 .024? 



Nota 



Recorded que el TCP es bi- 
direccional y que un seg- 
mento TCP reconoce, por 
medio de piggybacking , los 
datos que recibe con un 
ACK que debe estar nume- 
rado. 
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Solucion 

El numero de secuencia indica que el cliente ya ha 
transmitido desde el byte 28.325 hasta el byte 29.200 
(875 bytes en total) y que en este segmento transmitira 
a partir del byte 29.201. El numero ACK indicara al 
servidor que el cliente ha recibido correctamente hasta 
el byte 1 2.654 y que espera recibir a partir del 1 2.655. 

La ventana indica al servidor que el cliente solo puede 
aceptar 1.024 bytes antes de confirmarlos. Por consi- 
guiente, el servidor TCP actualizara su ventana de 
transmision a 1.024. 

Con el objetivo de estudiar el mecanismo de ventana deslizante, 
analizaremos un caso sencillo. Asumiremos que ya se ha establecido 
la conexion y se ha asignado la ISN para ambos extremos. 

En la figura siguiente, podemos ver como funcionaria el protocolo de 
ventana deslizante para el TCP transmisor. El TCP receptor le ha in- 
dicado que este dispuesto a recibir 7 bytes. Por tanto, la ventana de 
transmision de TCP transmisor es de 7 bytes: 



Figura 71 . 



Ventana = 7 bytes 



1004 1005 1006 



Bytes envwdos 
y ya reconoodos 


Bytes en/*ados, 
p«ro no roconocidos 


Ventana uiilizable 
$® 1® puedon onviar 
bytes si esian 
aisponibles 


No se pueden 
onviar bytes hasta 
que la ventana 
se muevo 


lirTvlo iiquivdo 


Verde 


■no [ 


4 limito dorocho 












La ventana 
sc cierra 


Lo ventano 
sc comp rime 


La ventana 
se abre 



Podemos interpretar la ventana deslizante de la manera siguiente: 



1 ) El TCP ha enviado bytes hasta el numero de secuencia 1 .003. De 
estos bytes, el TCP receptor le ha reconocido hasta el 999; fa I - 
tan por reconocerle los bytes 1.000 a 1.003. 
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2) Como la ventana de transmision es de 7 bytes y ya ha transmitido 
4, el TCP todavia puede transmitir 3 bytes antes de agotarla (bytes 
1.004 a 1.006). 

3) El TCP solo podra transmitir del byte 1 .007 en adelante en los ca- 
sos siguientes: 

• Si el TCP receptor le reconoce los bytes a partir del 1 .000, de 
manera que el limite izquierdo de la ventana se movera hacia 
la derecha. 

• Si el TCP receptor le advierte de una ventana superior a 7, de 
manera que el limite derecho de la ventana se movera hacia 
la derecha. 

• Una combinacion de las dos soluciones anteriores. 

Como podeis observar, el TCP receptor puede advertir una nueva 
ventana de transmision. Cada vez que reconozca datos, avisara de 
la nueva ventana que esta dispuesta a recibir. El TCP transmisor ac- 
tualizara esta ultima. 




La ventana puede experimentar tres tipos de movimiento: 



1) La ventana se cierra al moverse el limite izquierdo 
hacia la derecha cuando los datos enviados son re- 
conocidos. 

2) La ventana se abre al moverse el limite derecho hacia 
la derecha y permite que el TCP envie mas datos. Esta 
apertura tiene lugar cuando el receptor libera espacio 
de su memoria y puede advertir una nueva ventana. 

3) La ventana se comprime cuando el limite derecho 
se mueve hacia la izquierdo. 



Algunos puntos que podemos resumir de la figura de la ventana des- 
lizante son los siguientes: 



Si el limite izquierdo alcanza el limite derecho, se dice que la ventana 
vale cero (zero window ). Elio hace que el transmisor detenga el envio 
de datos. 
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• Se recomienda que el TCP transmisor no comprima la ventana de 
transmision. 

• Es preciso que distingamos el hecho de que la ventana se comprima 
(el Ifmite derecho se mueve hacia la izquierda) del hecho de que la 
ventana disminuya de tamaho (se advierte una ventana mas peque- 
na, pero el Ifmite derecho no se mueve hacia la izquierda). 



Not a 

Supongamos una ventana de 7 bytes como en la figura- 
de la ventana deslizante. El receptor reconoce los bytes 
1 .000 a 1 .003 y advierte una ventana de 5 bytes. Como 
podeis deducir, el Ifmite izquierdo vale ahora 1 .004; el 
Ifmite derecho, 1 .008 (se ha movido hacia la derecha), 
y la nueva ventana, 5. En este caso, la ventana de recep- 
cion debe reducirse, pero no se ha comprimido. 

En cambio, si el receptor solo reconoce 1 byte (el 
byte! .000) y advierte una ventana de 1 byte, el trans- 
misor se encontrara con un problema. Una ventana 
de 1 byte significa que solo podia haber transmitido 1 
(el 1.001), pero ya habfa transmitido 3, incluyendo el 
reconocido (del 1 .000 al 1 .003). Portanto, el receptor 
debe asegurarse de advertir al menos tantos bytes 
como el transmisor le puede haber enviado con la 
ventana anterior. Si solo reconoce 1 byte, la ventana 
advertida debe ser de 6 bytes; si reconoce los 4 bytes, 
esta ultima debe ser, al menos, de 3 bytes, puesto que 
el transmisor ya los podrfa haber transmitido. 



Ejemplo 

Utilizaremos el programa tcpdump para observar como funciona el 
protocolo de ventana deslizante. Asumimos que hemos efectuado un 
rlogin de argos a helios (argos % r login Helios ) y ya estamos co- 
nectados a helios. Una vez nos encontramos en helios, ejecutamos el 
comando Is. Este ultimo retorna por salida estandar el listado de di- 
rectories del directorio del usuario (lome directory) en helios que 
ocupan 81 1 caracteres (representa el envfo de 81 1 bytes) 

helios % Is 
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Las Ifneas que obtenemos con el programa tcpdump (numeradas 
del 1 al 13) son las siguientes: 



1) 15:56:59.506091 argos.1023 > helios . login : P 37:38 (l)ack 596 win 31744 

2) 15:56:59.516091 helios. login > argos.1023: P 596:597 (1) ack 38 win 8760 

3) 15 : 56 :. 59 . 526091 argos.1023 > helios . login: .ack 597 win 31744 

4) 15:56:59.846091 argos.1023 > helios . login : P 38:39 (l)ack 597 win 31744 

5) 15:56:59.856091 helios. login > argos.1023: : P 597:600 (3) ack 39 win 8760 

6) 15:56:59.866091 argos.1023 > helios . login : .ack 600 win 31744 

7) 15:57:00.116091 argos.1023 > helios . login : P 39:40 (l)ack 600 win 31744 

8) 15:57:00.126091 helios. login > argos.1023: P 600:603 (3) ack 40 win 8760 

9) 15:57:00.136091 argos.1023 > helios . login : .ack 603 win 31744 

10) 15:57:00.146091 helios. login > argos.1023: P 603:658 (55) ack 40 win 8760 

11) 15:57:00.156091 argos.1023 > helios . login : .ack 658 win 31744 

12) 15:57:00.166091 helios . login > argos.1023: P 658:1414 (756) ack 40 win 8760 

13) 15:57:00.176091 argos.1023 > helios . login : .ack 1414 win 31744 



La interpretacion de estas Ifneas es la siguiente: argos ya ha enviado 
36 bytes, mientras que helios ya ha enviado 595 (informacion que 
ambos han intercambiado desde el principio de la conexion, como 
pueden ser logins, usernames, etc.). Deducimos esta informacion de 
la primera Ifnea del ejemplo. 



1) argos envfa el caracter 'I'. El indicador P senala PUSH. El numero 
de secuencia avanza de 37 a 38. 

2) helios retorna un eco del caracter T. Su numero de secuencia avanza 
de 596 a 597 y reconoce el byte recibido (ACK = 37 + 1 = 38). 

3) argos reconoce el eco: ACK = 597 + 1 = 598. 

4) argos envfa el caracter 's'. El numero de secuencia avanza de 
38 a 39. El ACK no reconoce nada porque vale igual que an- 
tes: ACK = 597. 



Nota 



Recordad que PUSH indica 
al receptor que pase los da- 
tos inmediatamente a la 
aplicacion; es decir, que no 
los deje durante un tiempo 
en la memoria intermedia 
de recepcion. 



5) helios hace un eco que ocupa 3 bytes (BS + 1 + s). El numero de 
secuencia avanza tres posiciones (de 597 a 600) y reconoce el ca- 
racter 's' , puesto que ACK = 38 + 1 = 39. 

6) argos reconoce el eco con un ACK = 600. 

7) argos envfa el retorno de carro (CR). El numero de secuencia 
avanza una posicion. 



8) helios hace un eco del CRy, asimismo, retorna otro CR seguido 
de un LF. Elio significa el envfo de 3 bytes. Reconoce el CR, 
puesto que ACK = 40. 
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9) argos reconoce estos tres caracteres. 



10) helios responde a 'Is' enviando 55 de los 81 1 bytes que debe en- 
viar. El numero de secuencia avanza de 603 a 658. El ACK se men- 
tiene a 40. 

1 1) argos reconoce estos 55 bytes enviando un ACK de 659. 

1 2) helios transmite el resto de los 81 1 bytes, es decir, 756 bytes. 

1 3) argos reconoce estos bytes avanzando el ACK a 1 .414. 

Como podemos observar en este ejemplo, el TCP divide la informa- 
cion que hay que enviar en dos segmentos: un segmento de 55 
bytes y otro de 756 bytes. Conviene remarcar que rlogin envta los 
comandos caracter a caracter y que, ademas, la aplicacion remota 
hace un eco de estos caracteres. Por ello, en las primeras Itneas se 
envta primero la 'I', despues la 's', a continuacion el retorno de ca- 
rro, etc. Lo que nos interesa de este ejemplo es ver como avanzan 
las ventanas al emitir y al reconocer bytes. Por tanto, no justificare- 
mos por que rlogin retorna ecos, ni por que anade un caracter LF 
al retorno de carro. 



14.6.3. Temporizadores y retransmisiones 

El TCP activa hasta cuatro temporizadores de diferente tipo para 
conseguir una entrega fiable de la informacion. En este subapar- 
tado nos centraremos unicamente en eltemporizador de retrans- 
misiones o RTO (del ingles, retransmission time out). 



Conviene recordar que tanto los segmentos como los reconoci- 
mientos se pueden perder durante la transmision, de manera que 
es preciso utilizar un temporizador de retransmisiones. 



Como ya hemos mencionado, el temporizador se programa cada 
vez que se recibe un reconocimiento, o bien cuando salta porque 
el reconocimiento no ha llegado a tiempo (o, simplemente, no ha 
llegado). 
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Definimos el tiempo de ida y vuelta o RTT (del ingles, 
round trip time ) como el tiempo que transcurre desde 
que se transmite un segmento, hasta que es reconocido 
(el ACK vuelve al transmisor). El RTT se puede medir 
restando el instante en que el TCP transmisor emite el 
segmento y el instante en que recibe el ACK. 



Lo mas logico seria activar el temporizador de retransmision en el 
tiempo de ida y vuelta (RTO = RTT). Sin embargo, es evidente que 
los retardos que experimentan los segmentos son variables: si se 
activa el RTO en el RTT que ha experimentado el segmento ante- 
rior, no se puede asegurar que este segmento no tenga un retardo 
superior y que el temporizador no salte antes de tiempo. Por otra 
parte, si el temporizador se programa a un valor mucho mayor 
que RR, cada vez que haya una perdida estaremos esperando en 
balde un buen rato, con la consiguiente perdida de eficiencia. 



Existen diferentes alternativas para programar el temporizador, 
todas orientadas a encontrar un valor adecuado de RTT; es decir, 
que no sea demasiado corto ni demasiado largo. 



Lectura complementaria 



Podeis encontrar los dife- 
rentes algoritmos propues- 
tos para el caculo de RTT en 
la obra siguiente: 

W.R. Stevens (1994) 

"The protocols". TCP/IP 
llustrated (vol. 1) Willmington: 
Addison-Wesley. 
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IV. Aplicaciones Internet 



15. El modelo cliente/servidor 



Las redes de computadores han hecho aparecer un concepto nuevo 
en el mundo de la programacion: la programacion distribuida. Con 
esta ultima se pretende aprovechar la potencia y los recursos de los 
ordenadores interconectados para llevar a cabo una tarea de forma 
cooperativa. 



Una aplicacion distribuida esta formada por varios programas que 
se ejecutan en ordenadores diferentes y que se comunican por medio 
de la red que une a los ordenadores. 



Conviene destacar que cada programa, por sf solo, no 
puede hacer nada. Es necesaria la colaboracion de to- 
dos para que la aplicacion en conjunto produzca resul- 
tados utiles. 



La cooperacion de los diferentes trozos de codigo que forman la apli- 
cacion debe seguir un protocolo. Este ultimo se puede elaborar a 
medida para cada aplicacion que se desarrolle, o se puede definir 
un estandar que todo el mundo pueda seguir y asf ahorrarse, de este 
modo, los disenos particulares. Asimismo, la existencia de un proto- 
colo estandar garantiza la posibilidad de interactuar con productos 
de diferentes fabricantes. 



Existen varios estandares de aplicaciones distribuidas; sin embargo, 
sin lugar a dudas, el que ha tenido mas exito es el que sigue el mo- 
delo cliente/servidor. 



En el modelo cliente/servidor, la aplicacion se divide en 
dos partes, con dos roles claramente diferenciados: 



Servidor ofrece un servicio que puede ser el acceso a 
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un recurso, la ejecucion de operaciones matematicas 
complejas, procesamiento de datos, etc. 

Cliente: realiza una peticion al servidor y espera un re- 
sultado de la misma. 



Por norma general (al menos es lo que dice el modelo), los usuarios 
acceden a la aplicacion por medio del cliente. 



Figura 72. 




A 



El usuario de las aplicaciones puede ser una persona, pero tambien 
otra aplicacion. En el primer caso, el cliente debe disponer de una 
interfaz de usuario que permita el dialogo, canalizando las peticio- 
nes y mostrandole los resultados. En el segundo, el acceso se suele 
implementor con llamadas a funciones. 

El modelo se puede complicar si se anaden mas entidades a la apli- 
cacion distribuida. Veamos dos ejemplos: 

• Multiples clientes: 



Figura 73. 




El servidor debe estar preparado para recibir 
multiples conexiones, que pueden ser simultaneas. 






Multiples servidores: 



Figura 74. 




Varios servidores ofrecen servicios complementarios. Si el servi- 
dor no puede satisfacer la peticion del cliente, pero esta en con- 
tacto con otro servidor que sf que puede hacerlo, entonces se lo 
solicita. 

Los servidores pueden dialogar entre si con protocolos propios o 
siguiendo el modelo cliente/servidor. 



Desde el punto de vista del cliente, esta multiplicidad de servidores 
es completamente transparente: realiza una peticion a un servidor y 
espera una respuesta del mismo. 

Cuando diferentes servidores cooperan para ofrecer un servicio, ha- 
blamos de sistema servidor. 

La gran mayoria de las aplicaciones que se utilizan en Internet si- 
guen este modelo cliente/servidor. De aqui los nombres que se em- 
plean con asiduidad: servidor web, cliente de correo, servicio de 
nombres, etc. 



El diseno de una aplicacion distribuida que siga el mo- 
delo cliente/servidor incluye basicamente dos elemen- 
tos: la especificacion de los servicios que ofrece el 
servidor y la especificacion del protocolo de acceso, 
donde se describe como se piden estos servicios y como 
debe retornarse el resultado. 
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15.1. El modelo peer-to-peer 

El modelo cliente/servidor implica una cierta asimetria. Tendemos a 
ver los servidores como sistemas potentes que ofrecen sus servicios a 
maquinas mucho mas sencillas, los clientes. El gran desarrollo de In- 
ternet en su vertiente comercial ha contribuido a esta vision. Los 
usuarios de Internet, desde sus PC, tienen un claro comportamiento 
de cliente, accediendo a paginas web alojadas en servidores remo- 
tos, o enviando correos electronicos a otros usuarios. 

A medida que el uso de Internet ha madurado, los usuarios de la Red 
han sentido la necesidad de desempenar un papel mas activo, y con- 
verts sus maquinas en servidores que otros puedan aprovechar, o 
desarrollar nuevos modelos de aplicacion donde los roles no estan 
tan claramente diferenciados. Uno de estos modelos es el que se co- 
noce como peer-to-peer ('de igual a igual'), y las aplicaciones mas 
tipicas que siguen este modelo de comportamiento son los sistemas 
de comparticion de archivos o la mensajeria instantanea. 



Nota 

Diferentes caracteristicas de la Red que se han ido ana- 
diendo por cuestiones de seguridad o de eficiencia de la 
Red estan perjudicando mucho el desarrollo de entornos 
peer-to-peer. Podemos citar como las mas paradigmati- 
cas los cortafuegos, las direcciones IP dinamicas, el NAT 
( Network Address Translation ) y el ancho de banda asi- 
metrico que ofrecen en muchos casos los proveedores de 
Internet en los dos sentidos de transmision. La mayoria 
de aplicaciones intenta sobreponerse a estos obstaculos 
con estrategias mas o menos afortunadas. De todas for- 
mas, esta claro que en un futuro tienen que cambiar co- 
sas en el nivel de red para no limitar las enormes 
posibilidades que tenemos en el nivel de aplicacion. 



Nota 



El servicio DNS y el servicio 
News (o Usenet o NNTP), 
presentes en Internet desde 
sus inicios son claramente 
peer-to-peer. 



De hecho, Internet en su origen era peer-to-peer. Los primeros orde- 
nadores conecatodos a la Red eran parecidos, y una aplicacion 
como ftp permitfa la transferencia de archivos entre cualesquiera 
de estas maquinas. Dicho de otra forma, que el protocolo que usa la 
aplicacion siga el modelo cliente/servidor no es incompatible con 
que la red este formada por ordenadores de potencia parecida y en- 
tre el los se vean como una red peer-to-peer. 
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Porque en el fondo, si analizamos como funcionan las aplicaciones 
tfpicas de entornos peer-to-peer, como el extinto Napster, o Gnutella 
o ICQ o Jabber, verfamos que siguen protocolos tfpicos cliente/ser- 
vidor, tipo "yo te pido, tu me das". Lo que pasa es que en este tipo de 
entornos cualquiera puede hacer a la vez de cliente y de servidor. Por 
tanto, es erroneo considerar ambos modelos excluyentes. 




Un sistema puede ser peer-to-peer si presenta una cier- 
ta simetrfa en el sentido que las diferentes maquinas 
que lo componen son parecidas y pueden desempenar 
los mismos roles, y usar un modelo cliente/servidor en 
el desarrollo de las aplicaciones. 



Por otra parte, existen aplicaciones consideradas peer-to-peer por- 
que permiten la comunicacion directa entre iguales, pero que nece- 
sitan de un servidor externo (o varios) donde se centraliza el control 
de la red (Napster era un claro ejemplo de este modelo). Hay autores 
que son reacios a considerar estos entornos realmente peer-to-peer, 
y prefieren guardar el termino para aquellas redes donde solo inter- 
vienen las maquinas propiedad de los propios usuarios. No es obje- 
tivo de este material didactico entrar en esta discusion. 
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16. Servicio de nombres Internet 



La red Internet permite el acceso a una ingente cantidad de orde- 
nadores y, en general, de recursos, la mayoria de los cuales se 
pueden referenciar mediante un nombre. Por motivos de eficien- 
cia y simplicidad (poder saber con facilidad que recurso corres- 
ponde a cada nombre, poder asignar otros nuevos sin peligro de 
duplicidades o ambiguedades, etc.), todos los nombres de la red 
estan organizados de una manera jerarquica, formando unsiste- 
ma de dominios. 

Para obtener informacion referida a cualquier nombre, se utiliza un 
servicio que, funcionalmente, es como una base de datos: se le ha- 
cen consultas, que pueden incluir una serie de criterios de seleccion, 
y responde con la informacion solicitada. En un inicio, cuando el nu- 
mero de ordenadores conectados a la red era relativamente peque- 
no, esta base de datos era gestionada por una unica autoridad 
central, el Network Information Center (NIC). 

A medida que se expandia la Red, este modelo de gestion se iba 
haciendo cada vez mas inviable, tanto por el enorme trafico que 
generaban las consultas, como por la dificultad de mantener la in- 
formacion actualizada. Fue entonces cuando nacio el servicio de 
nombres de dominio (DNS), que sigue el modelo de una base de datos 
distribuida descentralizada. 

i : h 

Si quereis mas informacion sobre el DNS, podeis con- 
sular las obras siguientes: 

P.V. Mockapetris (1987,1 de noviembre). RFC 1034- 
Domain names - concepts and facilities. 

P.V. Mockapetris (1987, 1 de noviembre). RFC 1035- 
Domain names - implementation and specification. 
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La especificacion del DNS esta contenida en los documentos RFC 
1034, que define los conceptos y la organization del sistema de 
dominios, y RFC 1035, que define el protocolo de acceso al ser- 
vicio. 



1 6.1 . El sistema de nombres de dominio 



El sistema de nombres de dominio, en que se basa el DNS, propor- 
ciona un espacio de nombres para referenciar recursos, que por nor- 
ma general son ordenadores conectados a la red, pero que tambien 
pueden ser, por ejemplo, buzones de correo electronico. 



En el sistema de nombres de dominio, los nombres es- 
tan organizados jerarquicamente en forma de arbol. 
Cada nodo de este ultimo tiene una etiqueta que lo dis- 
tingue de sus nodos "hermanos". 



El nombre de dominio correspondiente a un nodo se 
define como la secuencia formada por las etiquetas 
existentes en el camino entre este nodo y la raiz. 



Nota 



A la hora de comparar 
nombres, las letras mayus- 
culas y minusculas se consi- 
deran equivalentes. No 
obstante, para responder 
las consultas, los servidores 
DNS deben enviar los nom- 
bres tal como estan almace- 
nados en la base de datos, 
respetando las mayusculas 
y minusculas, en prevision 
del caso de que en alguna 
version futura del servicio se 
consideren diferentes. 



Cada etiqueta constituye una cadena de caracteres de longitud com- 
prendida entre 0 y 63 caracteres. La etiqueta con longitud 0 esta re- 
servada para el nodo raiz: ningun otro nodo puede tener una 
etiqueta vacia. 



El protocolo de acceso al DNS define el formato para representor los 
nombres de dominio cuando deben enviarse en las consultas y las 
respuestas, como veremos mas adelante. Este formato no impone 
restricciones en los caracteres que puede haber en una etiqueta; sin 
embargo, establece una "sintaxis preferida" para facilitar las imple- 
mentaciones de otros servicios. De acuerdo con esta ultima, los uni- 
cos caracteres validos en una etiqueta son las letras, mayusculas o 
minusculas, los digitos decimoles y el simbolo con la excepcion 
de que el primer caracter solo puede ser una letra, y el ultimo no pue- 
de ser 
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Aparte de la representacion definida en el protocolo, cuando se de- 
sea utilizar una notacion textual para expresar un nombre de dominio, 
se sigue la convencion de concatenar las etiquetas que lo forman, sepa- 
randolas con el caracter En el orden utilizado, las etiquetas van 
desde el mas bajo nivel jerarquico mas bajo hasta el mas alto. Por 
tanto, la ultima etiqueta es la del nodo raiz que, como acabamos de 
observar, esta vacfa, de manera que los nombres acaban en 
como en el ejemplo siguiente: 



campus . uoc . edu . 



Notad la presencia del punto final. 



Este ejemplo es el que se denomina un nombre de dominio abso- 
lute, pero tambien pueden utilizarse nombres relativos, referidos 
a un nodo origen implicito. Asi, dentro del dominio uoc.edu. 
podemos utilizar el nombre tibet para referirnos al nombre de 
dominio tibet.uoc.edu.. En numerosas ocasiones, el nodo 
origen de los nombres relativos es la raiz, de manera que el ejem- 
plo anterior tambien puede escribirse del modo siguiente: 



campus . uoc . es 



Nota 



En el Reino Unido antes era 
usual utilizar el orden inverso 
en la representacion textual 
de los nombres de dominio, 
por ejemplo: 

uk . ac . ic . doc . sre en lu- 
gar de src.doc.ic.ac. uk; 

sin embargo, hoy d(a esta 
costumbre se encuentra en 
desuso. 



En un inicio, los TLD (top level domain, 'dominios de nivel supe- 
rior'); es decir, los subordinados directamente a la raiz, se utiliza- 
ban para agrupar los diferentes tipos de organizaciones a que 
pertenecian recursos como, por ejemplo, los que presentamos en 
la tabla siguiente: 



Tabla 6. 




Tipos de organizacion 


Nombre del dominio 


Empresas y organizaciones comerciales 


com 


Universidades y centros educativos 


edu 


Organismos gubernamentales 


gov 


Organizaciones militares 


mil 


Otros tipos de organizaciones 


org 



Nota 



En estos momentos, el orga- 
nismo encargado de gestio- 
nar los dominios es la 
ICANN. Podeis consultar su 
web: http://www.icann.org. 
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Desde entonces hasta la actualidad, se han ido anadiendo al nivel 
superior del sistema de nombres los elementos siguientes: 

a) Por un lado, nuevas closes de organizaciones, como net (centros 
relacionados con la gestion de la red), int (organizaciones inter- 
nacionales) o, mas recientemente, biz, info, name, pro, aero, 
coop y museum. 

b) Por otro lado, cada pais tiene asignado un nombre de dominio 
que coincide con el codigo correspondiente de dos letras especi- 
ficado en el estandar ISO 3166, por ejemplo: es (Espana), fr 
(Francia), de (Alemania), etc. Lo que significa que, en realidad, 
las diferentes ramas del arbol se pueden encabalgary, de hecho, 
hay nombres pertenecientes a diferentes dominios de alto nivel 
que corresponden a una misma organizacion. 

Asimismo, es posible que un determinado recurso (ordenador, buzon 
de correo, etc.) tenga asignados varios nombres, que pueden estar 
en la misma rama del arbol o en ramas completamente indepen- 
dientes. En este caso, se considera que uno de los nombres es el de- 
nominado nombre canonico y los otros se denominan alias. 



16.2. Modelo del DNS 



Los agentes que intervienen en el DNS son los siguientes: 



Nota 



Consultad ia definicion de 
sistema servidor en la uni- 
dad 1 5. 



a) Los servidores, que reciben las consultas y envlan las respuestas 
correspondientes. Ademas del acceso directo a una base de datos 
local, en la que se encuentra una parte de la base de datos total 
del sistema de nombres, el servidor tiene acceso indirecto al resto 
de la base de datos por medio de otros servidores. El conjunto de 
servidores DNS constituye, pues, un sistema servidor. 

b) Los resolvedores, que actuan como clientes del servicio. Por nor- 
ma general, un resolvedor es un programa o una librerla que re- 
cibe peticiones de las aplicaciones de usuario, las traduce a 
consultas DNS y extrae de las respuestas la informacion solicita- 
da. El resolvedor debe tener acceso directo al menos a un servidor 
DNS. 
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Nota 



Utilizacion del resolvedor 

Una aplicacion que sirva para copiar ficheros almace- 
nados en otros ordenadores puede aceptar que el 
usuario indique a que ordenador desea acceder por 
medio de su nombre. Por consiguiente, para poderse 
comunicar con el, la aplicacion debera realizar una 
llamada al resolvedor para obtener su direccion a 
partir del nombre. Como la aplicacion y el resolvedor, 
por lo general, se encontraran ubicados en el mismo 
sistema, no es necesario establecer ningun protocolo 
de comunicacion entre ellos. 

Para hacer manejable la gestion y administracion del sistema de 
nombres de dominio, sus nodos estan agrupados en zonas. Cada 
zona esta formada por un nodo llamado superior y todos los que se 
encuentren en los niveles jerarquicamente inferiores hasta llegar a 
los nodos terminales (las hojas del arbol) o a nodos de otras zonas 
que sean superiores. 

La figura siguiente muestra un ejemplo de division de un arbol en 
cuatro zonas: 




Nota 



Como cada zona se suele 
denominar con el nombre 
de dominio de su nodo su- 
perior, podemos decir que 
las zonas de la figura son A, 
B.A, C.Ae I.C.A. 



El objetivo de agrupar los nodos en zonas consiste en asignar a una au- 
toridad la responsabilidad de gestionar todos los nodos de cada zona. 
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El administrador designado para esta autoridad puede anadir o borrar 
nodos dentro de su zona, modificar la informacion de sus nodos o crear 
nuevas subzonas y delegar su gestion en otras autoridades. 



Ejemplo 



Una zona puede correspon- 
der a un pais y sus subzonas 
pueden corresponder a or- 
ganizaciones de este pais. 
Cada organization, a su 
vez, puede crear subzonas 
para diferentes departa- 
mentos, etc. 



La informacion referida a una zona debe estar almacenada en la base 
de datos local de un servidor, del que se dice que es un servidor con au- 
toridad sobre esta zona. Este ultimo puede contestar directamente las 
consultas que reciba sobre los nodos de su zona, sin necesidad de ac- 
ceder a otros servidores. Es decir, en este caso, el servidor enviara res- 
puestas con autoridad. 

Si una consulta se refiere a otra zona, existen dos maneras posibles de 
generar la respuesta: 



• En el modo no recursivo, la respuesta unicamente incluye una refe- 
renda a algun servidor que puede proporcionar mas informacion. El 
cliente debe preocuparse de continuar realizando consultas hasta 
encontrar la respuesta definitiva. 



• Si el cliente solicita el modo recursivo, es el servidor quien se ocupa 
de buscar la informacion donde sea preciso, y solo puede retornar la 
respuesta final o un error, pero no referencias a otros servidores. 



La especificacion DNS establece que todos los servidores deben sopor- 
tar el modo no recursivo, y que el modo recursivo es opcional, aunque 
en la practica, la mayorta de las consultas de los clientes son en modo 
recursivo. 



Cuando un servidor debe responder a una consulta en modo re- 
cursivo, pide la informacion a otros servidores y envta la respuesta 
recibida a quien ha realizado la consulta. Es habitual que el ser- 
vidor anada la informacion obtenida a su base de datos, en lo que 
se denomina cache. De este modo, si recibe otra consulta (del 
mismo cliente o de otro) en la que se solicita la misma informa- 
cion, no sera necesario que se la pida de nuevo a otros servidores, 
sino que puede aprovechar la ya existente en la cache. Sin embar- 
go, es posible que los datos se hayan modificado en el servidor 
de origen desde que se solicitaron por primera vez. En este caso, 
pues, el servidor debe avisar al cliente de que le envta una res- 
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puesta sin autoridad. Por otro lado, los resolvedores tambien sue- 
len guardar en una cache propia las respuestas que reciben de los 
servidores. 

Para ofrecer una alta fiabilidad en el servicio, la especificacion DNS 
requiere que para cada zona haya como mfnimo dos servidores con 
autoridad que, por norma general, responden a las siguientes fun- 
ciones: 



a) Uno actua como servidor primarioy guarda los ficheros origina- 
les de la base de datos correspondiente a la zona; es decir, aque- 
I los que el administrador debe actualizar directamente cada vez 
que haya una modificacion en sus nodos. 

b) Los otros actuan como servidores secundarios y actualizan auto- 
maticamente sus bases de datos a partir de la del primario; por 
ejemplo, por medio de consultas periodicas para saber si se ha 
producido algun cambio. De este modo, si un servidor primario 
esta temporalmente inaccesible (por una cafda de la red, del mis- 
mo servidor, etc.), los clientes pueden enviar sus consultas a uno 
de los servidores secundarios. 



Nota 



En el argot DNS, refrescar 
los datos significa actuali- 
zarlos realizando consultas 
periodicas. 



La figura siguiente muestra una posible configuracion del servicio 
DNS en un ordenador: 




En la practica, se pueden encontrar muchas variantes de este esque- 
ma; por ejemplo, que el servidor DNS se encuentre en el mismo or- 
denador que el resolvedor y que ambos compartan la cache, que el 
resolvedor tenga acceso a diferentes servidores DNS, etc. 
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1 6.3. Base de datos DNS: los registros de recurs© 



Como hemos visto en los subapartados anteriores, un nombre del 
sistema de dominios identifica un nodo, y para cada nodo puede ha- 
ber cierta informacion almacenada en los servidores correspondien- 
tes. El objetivo del servicio DNS consiste en permitir la obtencion de 
dicha informacion a partir del nombre de dominio. 



La informacion asociada a un nodo consta de un con- 
junto de registros de recurso. Los registros de recurso de 
todos los nodos forman la base de datos DNS. 



Cada registro de recurso consta de los campos siguientes, que se ex- 

plican a continuacion: 

• Nombre. 

• Tipo. 

• Close. 

• Tiempo de vida. 

• Datos del recurso. 

a) Nombre. Contiene el nombre de dominio del nodo al que esta 
asociado el registro. 

b) Tipo. Indica que tipo de informacion contiene el registro. Los va- 
lores que podemos encontrar en este campo y los tipos de infor- 
macion que representan son los siguientes: 

• A: direccion de un ordenador. 

• CNAME: nombre canonico de un alias. 

• HINFO: informacion sobre el tipo de ordenador. 

• MX (Mail eXchanger ): nombre de un servidor de correo electronico 
para un dominio. 

• NS: nombre de un servidor DNS con autoridad para una zona. 

• PTR: nombre de un dominio que contiene informacion relaciona- 
da con un nodo. 

• SOA ( Start Of Authority): informacion sobre el nodo superior de 
una zona. 
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Otros valores posibles del campo Tipo son los siguientes: 



• MB: nombre de un buzon de correo. 

• MG: miembro de un grupo de correo. 

• MR: nombre nuevo de un buzon de correo. 

• MINFO: informacion sobre un buzon o una lista de distribucion de 
correo. 

• WKS (We// Known Services): lista de servicios que proporciona un 
ordenador. 

• TXT: texto descriptivo. 

• NULL: registro vacfo. 



c) Clase. Indica la familia de protocolos utilizada en el espacio de 
nombres. Por norma general, sera la familia de protocolos Inter- 
net, pero puede haber otros. 

d) Tiempo de vida (TTL). Indica el tiempo maximo que un servidor 
o un resolvedor puede guardar el registro en su cache. 

e) Datos del recurso (RDATA). El valor de este campo depende del 
tipo de registro: 

• Si el registro es de tipo A, en la clase Internet, el valor es un numero 
de 32 bits que corresponde a una direccion IP. 

• Si el registro es de tipo CNAME, el valor es un nombre de dominio 
que corresponde al nombre canonico del alias asociado con el re- 
gistro. Si un nodo del arbol de nombres es un alias, la unica in- 
formacion que puede tener asociada es un registro CNAME. 



Nota 



El sistema de nombres de 
dominio proporciona un 
conjunto de espacios de 
nombres, uno para cada 
clase, todos sobre un mismo 
arbol. Los datos correspon- 
dientes a un nodo en una 
clase pueden ser diferentes 
de las del mismo nodo en 
otra clase (un nodo puede 
no tener ningun registro de 
recurso de alguna clase), 
puesto que las bases de da- 
tos (como las divisiones en 
zonas) son separadas e in- 
dependientes. 



• Si el registro es de tipo HINFO, el valor es una cadena de caracteres. 



• Si el registro es de tipo MX, el valor tiene dos subcampos, el pri- 
mero es un numero que representa una preferencia (cuanto me- 
nor es el numero, mas preferencia) y el segundo es el nombre de 
un ordenador que esta dispuesto a aceptar mensajes destinados 
al dominio correspondiente al registro. 
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Nota 



El estandar RFC 974 especifica como deben utilizarse 
los registros MX para direccionar un mensaje de correo 
electronico dada la direccion del destinatario (por 
ejemplo, usuari@uoc . edu). De esta direccion se se- 
para a parte correspondiente al dominio de correo 
(uoc.edu), se consulta el sistema DNS para saber 
que servidores aceptan correo para este dominio y se 
elige uno teniendo en cuenta su preferencia. Si la co- 
municacion con este servidor no tiene exito, se intenta 
con los otros por orden de preferencia. 

Si no hay ningun registro MX asociado al dominio, se 
entiende que solo dispone de un servidor de correo: el 
ordenador que tenga por nombre el del dominio. 



• Si el registro es de tipo NS, el valor es un nombre de ordenador. 



• Si el registro es de tipo PTR, el valor es un nombre de dominio. 



Nota 



Cada nodo que sea el supe- 
rior de una zona debe tener 
asociado un registro SOA. 



Nota 



El nombre del buzon puede 
expresarse como un nom- 
bre de dominio siguiendo la 
sintaxis general de separar 
los nombres de los nodos 
con (en este caso, la par- 
te correspondiente al usua- 
rio seria el nodo inferior). 

Por ejemplo, en el buzon 

usuari@uoc.edu le co- 

rresponde el nombre de do- 

miniousuari.uoc. edu. 



Si el registro es de tipo SOA, el valor del campoRDATA en un registro 

de este tipo esta formado por los siete subcampos siguientes: 

- MNAME: nombre del servidor primario de la zona. 

- RNAME: nombre de dominio correspondiente al buzon del res- 
ponsable de la zona. 

- SERIAL: numero que debe aumentarse cada vez que haya 
una modificacion en los datos de la zona. 

- REFRESH: tiempo que debe transcurrir para que los servidores 
secundarios refresquen sus datos. 

- RETRY: tiempo que es preciso esperar para volver a intentar 
un refresco si no se ha conseguido contactor con el servidor 
primario. 

- EXPIRE: tiempo maximo a partir del cual los datos de un ser- 
vidor secundario se consideraran sin autoridad si no se han re- 
frescado. 

- MINIMUM: valor mfnimo del campo TTL en los registros de la 
zona. 
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Nota 



Refresco de una zona en un servidor secundario 

El proceso de refresco de una zona en un servidor se- 
cundario consiste en pedir al primario su registro SOA 
y comprobar si ha variado el campo SERIAL. Si ha 
variado, es preciso llevar a cabo una transferencia de 
los datos de la zona (por ejemplo, con una peticion 
AXFR del protocolo DNS, por medio del protocolo 
FTP, etc.) y, si no, no es necesario hacer nada. 



El protocolo de acceso al DNS, como veremos en el subapartado si- 
guiente, define el formato de representacion de los registros de re- 
curso en las respuestas de los servidores. Sin embargo, tambien es 
habitual utilizar una representacion textual; por ejemplo, en los fiche- 
ros de la base de datos que el administrador de una zona puede edi- 
tor y actualizar. La sintaxis tfpica de esta representacion textual es la 
siguiente: 



[nombre] ( [clase] [TTL] | [TTL] [clase] ) tipo RDATA 



Cada registro se escribe en una Ifnea; sin embargo, si es dema- 
siado largo, se pueden utilizar parentesis, dentro de los cuales se 
ignoran los saltos de Ifnea. El sfmbolo sirve para introducir 
comentarios en el mismo. El campo Nombre es opcional (por de- 
fecto se toma el del registro anterior), como tambien lo son cla- 
se (el valor del campo clase, por norma general, es IN, que 
correspoonde a la clase Internet) y TTL, que se pueden escribir 
en cualquier orden. Los campos que representan dominios pue- 
den ser absolutos (acabados en ".") o relativos (respecto a un 
origen preestablecido), y los que representan tiempo se expresan 
en segundos. 

El campo Nombre puede empezar con la etiqueta "*" para indicar 
que la informacion del registro se aplica a los dominios que ten- 
gan cualquier etiqueta o secuencia de etiquetas en el lugar del "*" 
y no figuren en ningun otro registro. 
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Nota 



Li'neas del fichero de datos de un servidor acme . com 

Estas podrfan ser algunas Ifneas del fichero de datos de un 
hipotetico servidor de la zona acme . com: 



acme.com. IN SOA servidor.acme.com. admin.acme.com. ( 

38 ; SERIAL 

7200 ; REFRESH 

600 ; RETRY 

3600000 ; EXPIRE 

60 ) ; MINIMUM 





NS 


servidor . acme . com . 




NS 


servidor2 . acme . com. 




NS 


dns . competencia . com. 




MX 


10 correo.acme.com. 




MX 


20 servidor.acme.com 


* . acme . com . 


MX 


10 correo.acme.com. 


servidor . acme . com . 


A 


128.52.46.32 




A 


128.32.11.99 


servidor2 . acme . com . 


A 


128.52.46.33 


cor reo . acme . com . 


A 


128.52.46.34 



Un uso habitual de los registrosPTR es facilitar la obtencion del nombre 
de un ordenador a parfir de su direccion por medio de un dominio es- 
pecial denominado IN-ADDR. ARPA. El DNS proporciona una opera- 
cion para efectuar consultas inversas; es decir, dado un registro, retorna 
el nombre de dominio a que corresponde. Sin embargo, esta operacion 
puede ser muy costosa para el servidor, y no se puede garantizar que la 
respuesta sea unica o completa, puesto que puede haber otros servido- 
res que contengan informacion relacionada. 



No obstante, como la traduccion de direcciones IP a nombres es util e, 
incluso, necesaria, en algunos protocolos (por ejemplo, rlogin y rsh) se 
ha adoptado un mecanismo para facilitarla que consiste en introducir 
registros adicionales que actuan como fndice. De este modo, cada vez 
que se modifica una direccion en la base de datos DNS, o se anade una, 
es necesario actualizar dos registros: 



• El registro A que tiene por nombre el del ordenador. 



• Un registro PTR que tiene un nombre perteneciente al dominio 

IN-ADDR. ARPA 



Los nombres del dominio IN-ADDR. ARPA pueden tener hasta cua- 
tro etiquetas (sin contar IN-ADDR y ARPA), que representan los valo- 
res posibles de los bytes de una direccion IP en decimal, entre 0 y 
255. De estas etiquetas, la de nivel mas alto corresponde al primer 
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bytede la direccion, y la de nivel mas bajo, al ultimo byte. De este 
modo, se puede tener una estructura de zonas y autoridades delega- 
das similar a la del resto de los dominios. Un nombre del dominio 
IN-ADDR. ARPA que posea las cuatro etiquetas numericas corres- 
ponded a la direccion de un ordenador, y se le asociara un registro 
PTR que apunte al nombre de este ordenador. Los nombres que dis- 
pongan de menos de cuatro etiquetas numericas seran direcciones 
de redes y podran tener asociados registros PTR apuntando al nom- 
bre de las pasarelas conectadas a estas redes. 



Nota 

Registros de traduccion 

Siguiendo el ejemplo anterior, los registros del dominio IN- 
ADDR. ARPA siguientes podrfan servir para llevar a cabo la 
traduccion de direcciones a nombres: 



32.46.52. 


128 . IN-ADDR. ARPA. 


PTR 


servidor . 


acme . 


com . 


33.46.52. 


12 8 . IN-ADDR. ARPA. 


PTR 


servidor2 


. acme 


. com 


34.46.52. 


128 . IN-ADDR. ARPA. 


PTR 


correo . acme . com . 


99.11.32. 


128 . IN-ADDR. ARPA. 


PTR 


servidor . 


acme . 


com . 


46.52.128 


. IN-ADDR. ARPA. 


NS 


servidor . 


acme . 


com . 






NS 


servidor2 


. acme 


. com 






PTR 


servidor . 


acme . 


com . 


11.32.128 


. IN-ADDR. ARPA. 


NS 


servidor . 


acme . 


com . 






NS 


servidor2 


. acme 


. com 






PTR 


servidor . 


acme . 


com . 



Nota 



Los nombres del dominio 
IN-ADDR. ARPA son una 

excepcion a la sintaxis pre- 
ferida para las etiquetas, 
puesto que deben empezar 
con un dfgito. 



16.4. Protocolo 

1 6.4.1 . Mecanismos de transporte 

Para acceder al DNS se pueden utilizar los protocolos de transporte UDP 
o TCP. Por norma general, se utiliza UDP en las consultas de los clientes, 
por su simplicidad y por los pocos recursos que requiere. Si no llega la 
respuesta a un datagrama en un tiempo determinado, simplemente se 
retransmite (hasta que haya transcurrido un tiempo maximo). En cam- 
bio, se utiliza TCP cuando conviene asegurar una transmision fiable; por 
ejemplo, en las transferencias de datos de una zona de un servidor a 
otro. Tanto en un caso como en el otro, el numero de puerto utilizado 
es el 53. 
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Las consultas y las respuestas se intercambian por medio de mensajes, 

cuyo formato depende del protocolo que se utilice: 

• En UDP, cada mensaje se envfa en un datagrama, con una longitud 
maxima de 512 bytes. 

• En TCP, los mensajes se envfan prefijados con 2 bytes, que indican 
su longitud, para saber donde acaban, puesto que lo mas normal es 
intercambiar mas de uno utilizando una misma conexion. 

16.4.2. Mensajes 

El esquema siguiente muestra la estructura de un mensaje DNS: 



Figura 77. 




Cada mensaje esta formado por una cabecera y cuatro secciones 
(pregunta, respuesta, autoridad e informacion adicional). 

La cabecera consta de los campos siguientes: 



• ID es un numero de 1 6 bits que asigna quien realiza la consulta 
y que se copia en la respuesta para que se sepa a que consulta 
corresponde. 
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• QR (Query/Response) es un bit que indica si el mensaje es una con- 
sulta (0) o una respuesta (1). 

• OPCODE es un codigo de operacion de 4 bits. En la actualidad, 
hay definidos los de consulta directa (QUERY, codigo 0), consulta 
inversa ( I QUERY, codigo 1 ) y peticion de estatus (STATUS, codigo 2). 
Por norma general, el valor de este campo sera QUERY, puesto 
que la operacion I QUERY es opcional y poco soportada, y la ope- 
racion STATUS no esta definida en la especificacion RFC 1034. 

• AA (Authoritative Answer ) es un bit que informa de que el men- 
saje es una respuesta con autoridad. 

• TC ( Truncation ) es un bit que aviso que el mensaje se ha trun- 
cado porque no cabe en un datagrama. Para saber cual es su 
contenido completo, es preciso utilizar el protocolo TCP. 

• RD ( Recursion Desired) es un bit que indica que el cliente soli- 
cita respuesta en modo recursivo. 

• RA ( Recursion Available ) es un bit que informa de que el servidor 
soporta el modo recursivo. Si los bits RD y RA valen 1 , el men- 
saje es una respuesta recursivo. 

• RCODE es un codigo de respuesta de 4 bits. Los codigos posi- 
bles son: ningun error (0), error de formato (1), error interno 
del servidor (2), dominio inexistente (3), operacion no imple- 
mentada (4) o consulta rechazada (5). 

• QD COUNT , ANCOUNT, NSCOUNT, ARCOUNT son numeros de 
16 bits que indican cuantas entradas hay en cada seccion del 
mensaje: pregunta, respuesta, autoridad e informacion adicio- 
nal, respectivamente. 



Seccion de pregunta 

Los mensajes correspondientes a las consultas dispondran de una o 
mas entradas (por lo general, una) en la seccion de pregunta. Cada 
entrada esta formada portres campos: 



QNAME: nombre de dominio del que el cliente desea obtener in- 
formacion. 
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• QTYPE: numero de 16 bits que indica el tipo de registro de re- 
curso que el cliente quiere obtener como respuesta. El valor de 
dicho campo puede ser cualquiera de los numeros que pueden 
encontrarse en el campo TYPE de un registro, o uno de los si- 
guientes: 

- XFR (codigo 252): se utiliza para solicitor la transferencia de 
todos los registros de una zona (cuando un servidor secunda- 
rio quiere refrescar su base de datos). 

- MAILB (codigo 253): sirve para solicitor todos los registros re- 
lacionados con buzones (MB, MG y MR). 

- * (codigo 255): sirve para pedir todos los registros de cual- 
quier tipo correspondientes a un nombre. 

• QCLASS: numero de 16 bits que indica la close de registros desea- 
dos. Su valor puede ser el del campo CLASS de los registros o el va- 
lor especial (codigo 255), que representa todas las closes. 



Seccion de respuesta 

Los mensajes correspondientes a las respuestas contienen en la sec- 
cion de respuesta el conjunto de registros de recurso que satisfacen 
los criterios dados por los campos de la consulta. Es decir, el servidor 
envla en la respuesta los registros correspondientes al nombre solici- 
tado que concuerdan con el tipo o con los tipos requeridos y en la 
close o closes requeridas. 

Un caso especial es el de los alias. Si el nombre solicitado correspon- 
de a un alias y el campo QTYPE es diferente de CNAME, el servidor 
debe repetir automaticamente la consulta sustituyendo el nombre 
original por el nombre canonico. De este modo, el cliente obtendra 
directamente los datos deseados tanto si utiliza un alias, como si em- 
plea el nombre canonico. 



La respuesta a una peticion AXFR consistira en una secuencia de 
mensajes. El primero debe contener el registro SOA de la zona; en 
los siguientes deben encontrarse el resto de los registros, y el ultimo 
debe ser otra vez el registro SOA, para que el receptor sepa que ya 
ha acabado la transferencia. 
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Seccion de autoridad 



En una respuesta, la seccion de autoridad puede contener registros 
que referencien un servidor con autoridad para responder la consul- 
ta (para el caso de las respuestas en modo no recursivo). 

Seccion de informacion adicional 

La seccion de informacion adicional puede contener otros registros 
de recurso relacionados con la consulta, pero que no forman parte de 
la respuesta. 



16.4.3. Representacion de los registros de recurso 

Cuando un mensaje debe contener una cadena de caracteres, se 
representa por medio de 1 byte, que indica su longitud y, a con- 
tinuacion, los caracteres de la cadena. Un nombre de dominio se 
representa como una concatenacion de cadenas, una para cada 
una de las etiquetas que lo forman. Como los nombres de domi- 
nio acaban con la etiqueta del nodo rafz, una cadena que tenga 
por longitud 0 (y, por tanto, ningun caracter a continuacion) indi- 
ca el final del nombre. Para simplificar la implementacion del ser- 
vicio, la especificacion RFC 1035 requiere que la longitud total de 
un nombre de dominio no sea superior a 255 bytes. 



Nota 

Representacion comprimida de los nombres de 
dominio 

La especificacion RFC 1035 tambien define una repre- 
sentacion comprimida de los nombres de dominio cuan- 
do hay muchos iguales, o que acaban igual, en un 
mensaje (como es el caso de los que contienen registros 
SOA). En lugar de una etiqueta, en un nombre puede ha- 
ber 1 byte con los 2 bits de mas peso a 1 (por tanto, no 
se puede confundir con la longitud de una etiqueta, que 
como maximo puede ser 63). Los otros 6 bits y los 8 del 
byte siguiente indican una posicion dentro del mensaje 
en que se encuentra la continuacion del nombre. 
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La representacion de los registros de recurso que pueden aparecer 
en las secciones de respuesta, autoridad e informacion adicional si- 
gue el formato siguiente: 




Los campos que forman los registros de recurso dentro de los men- 
sajes DNS son los siguientes: 

• El campo NAME es el nombre de dominio correspondiente al re- 
gistro. 

• El campo TYPE es un numero de 16 bits que indica el tipo de 
registro, segun la tabla siguiente: 



Tabla 7. 



Numero 


Tipo de registro 


1 


A 


2 


NS 


5 


CNAME 


6 


SOA 


7 


MB 


8 


MG 


9 


MR 


10 


NULL 


1 1 


WKS 


12 


PTR 


13 


HINFO 


14 


MINFO 


15 


MX 


16 


TXT 
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• El campo CLASS es un numero de 1 6 bits que indica la close del 
registro. Por norma general, su valor es 1, que corresponde a la 
close Internet. 

• El campo TTL es un numero de 32 bits que indica el tiempo de 
vida del registro en segundos. 

• El campo RDLENGTH es un numero de 1 6 bits que indica cuantos 
bytes hay en el campo RDATA. 

• El campo RDATA contiene los datos del registro, y su formato de- 
pende del valor del campo TYPE: 

- En los registros A (de la close Internet), es un numero de 32 bits. 

- En los registros CNAME, NS, PTR, MB, MG y MR, es un nombre 
de dominio. 

- En los registros SOA, es una secuencia de dos nombres de do- 
minio (MNAME y RNAME) seguida de cinco numeros de 32 bits 

(SERIAL, REFRESH, RETRY, EXPIRE y MINIMUM). 

- En los registros MX, es un entero de 1 6 bits (la preferencia) se- 
guido de un nombre de dominio. 

- En los registros HINFO, es la concatenacion de dos cadenas de 
caracteres. La primera indica el tipo de UCP del ordenador, y 
la segunda, el sistema operativo. 

- En los registros WKS, es un numero de 32 bits, como en los re- 
gistros A, seguido de un numero de 8 bits que identifica un 
protocolo (por ejemplo, 6 = TCP; 1 7 = UDP) y una secuencia 
de bits en la que cada bit indica si el ordenador ofrece un de- 
terminado servicio o no. 

- En los registros MINFO, es la concatenacion de dos nombres 
de dominio. El primero constituye la direccion del responsable 
del buzon o lista de distribucion, y el segundo, la direccion 
donde deben enviarse las notificaciones de error. 

- En los registros TXT, es una cadena de caracteres. 

- En los registros NULL, puede ser cualquier cosa. 
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16.5. Implementaciones del DNS 



Practicamente todos los ordenadores conectados a la red Internet 
incorporan alguna implementacion de un cliente DNS (por norma 
general, una libreria de funciones llamadas por las aplicaciones) 
para poder acceder a otros ordenadores conociendo los nombres 
de los mismos. Este es el caso, por ejemplo, de los sistemas Unix o 
GNU/Linux, que proporcionan funciones como gethostbyname 
o gethostbyaddr. 

En muchos sistemas Unix o GNU/Linux tambien se encuentra dispo- 
nible una utilidad denominada nslookup, que sirve para efectuar 
consultas directamente a un servidor DNS. En el modo de funciona- 
miento basico, acepta comandos como los siguientes: 

• nombre: envia una consulta utilizando el nombre especificado 
como valor del campo QNAME y muestra los resultados obtenidos, 
indicando si la respuesta es sin autoridad. En caso de serlo, infor- 
ma de que registros ha enviado el servidor en la seccion de auto- 
ridad de la respuesta. 

• server servidor: cambia el servidor por defecto al que se en- 
vian las consultas. 

• Is dominio: muestra una lista de nodos del dominio e informa- 
cion asociada; si la lista es muy larga, se puede guardar en un 
fichero anadiendo > fichero. 

• set querytype= tipo: permite cambiar el campo QTYPE de las 
consultas que, por defecto, es A, a cualquier otro valor (NS, MX, 
PTR, CNAME, etc.). 

• set q=tipo: es equivalente a set querytype. 

• set domain=origen: cambia el dominio origen que debe utili- 
zarse cuando se especifica un nombre relativo. 

• set opcion: cambia el valor de alguna opcion utilizada por el pro- 
grama. Si el valor es recurse, pide que las consultas se lleven a 
cabo en modo recursivo. Si el valor es norecurse, pide que se rea- 
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licen en modo no recursivo. Si el valor es vc, pide que se utilicen "cir- 
cuitos virtuales", es decir, el TCP. Si el valor es novc, pide que se 
empleen datagramas, o lo que es lo mismo, el UDP, etc. 

• set all: muestra el valor actual de los parametros con que tra- 
baja el programa (servidor por defecto, opciones, lista de nodos 
origen que debe utilizarse cuando se consultan nombres de do- 
minio relativos, etc.). 

• ?: muestra un mensaje de ayuda. 

• exit: acaba el programa. 



Actividad 

Utilizad el programa nslookup para responder a estas 
preguntas: 

a) zCual es la direccion del ordenadorwww.uoc.es? 

b) zQue ordenador u ordenadores tienen por alias 

ftp . uoc . es? 

c) 2Cual es el servidor DNS del dominio uoc . es ? 2y 
el del dominio uoc . edu? 

c) 2Cual es el servidor del dominio de correo cam- 
pus . uoc . es? 



191 



17. Servicios basicos de Internet 



17.1. Terminal virtual: el protocolo Telnet 

Uno de los servicios basicos para los que se puede utilizar una red 
de comunicaciones entre computadores es el acceso por medio de 
un terminal. Cuando se desarrollaron los sistemas multiusuario, la 
manera habitual de trabajar en los mismos consistia en utilizar un 
equipo terminal (en un inicio, un teletipo y, mas adelante, un dispo- 
sitivo con teclado y pantalla) conectado directamente al ordenador, 
en general por medio de una linea serie. El ordenador debia saber 
que terminales tenia conectados y como podia controlarlos. 



Nota 



El hecho de que en una pri- 
mera epoca se utilizaran te- 
letipos es el motivo por el 
cual en UNIX se utilizo la 
abreviacion tty ( teletype ) 
para designar los termina- 
les (basicamente, impreso- 
ras con teclado). 



Con la llegada de las redes de comunicaciones, que permitian inter- 
conectar diferentes ordenadores, uno de sus usos naturales era man- 
tener una sesion de trabajo interactive con un ordenador remoto sin 
necesidad de utilizar los terminales que estuvieran conectados al 
mismo directamente. Para ello, era preciso establecer un protocolo 
que, por un lado, hiciera posible que el ordenador remoto y el siste- 
ma en que queria trabajar el usuario se pudieran comunicar y se en- 
tendieran (es decir, un protocolo en el ambito de aplicacion, puesto 
que el problema del transporte se supone que ya estaba resuelto) y, 
por otro lado, facilitara el control del terminal del usuario desde el 
ordenador remoto. 



Un ordenador puede permitir que se acceda al mismo desde cual- 
quier terminal de cualquier otro ordenador conectado a la red; sin 
embargo, no es practico que deba saber como se controlan todos los 
tipos posibles de terminal. La solucion general a estos requisitos se 
basa en el uso de un protocolo de terminal virtual. 



Un terminal virtual es un dispositivo imaginario para 
el que se definen unas funciones de control canonicas, 
de manera que se puede establecer una corresponden- 
ce entre ellas y las de cada tipo de terminal real. 
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Lectura complementaria 



Si quereis mas informacion 
sobre el protocolo Telnet, 
consultad la obra siguiente: 
J. Pastel; J.K. Reynolds 
(1983, 1 de mayo ). RFC 854 
- Telnet Protocol Specification. 



Nota 



El usuario del terminal pue- 
de ser una persona o un 
proceso. 

Los datos leidos en el primer 
caso por norma general se- 
ran los caracteres tecleados 
y, en el segundo, los que 
vaya generando el proceso. 
La presentacion de los datos 
recibidos puede consistir en 
escribirlos en la pantalla, 
enviarlos a la impresora o 
pasarlos al proceso usuario. 



En el entorno Internet, el protocolo de terminal virtual mas utilizado 
es Telnet, cuya especificacion se publico en 1983 en el estandar RFC 
854. 



17 . 1 . 1 . Principios basicos del protocolo Telnet 



El protocolo Telnet esta basado en el protocolo de transporte TCP. En 
una comunicacion Telnet, por norma general se sigue el modelo 
cliente/servidor; es decir, el sistema usuario establece una conexion 
con el sistema proveedor, que esta esperando peticiones de conexion 
en un puerto determinado. Se puede utilizar cualquier numero de 
puerto para las conexiones y, de hecho, existen muchas aplicaciones 
que utilizan el protocolo Telnet para la comunicacion, cada una con 
su propio numero. La aplicacion basica, sin embargo, consiste en es- 
tablecer una sesion de trabajo interactive con el sistema servidor y, 
en este caso, el numero de puerto utilizado es el 23. 



Para resolver el problema del control del terminal en la 
aplicacion de sesiones interactivas, en el protocolo Te- 
lnet se utiliza el concepto de terminal virtual de red o 
NVT. Un NVT es un terminal virtual con una funciona- 
lidad muy basica, definida en la misma especificacion 
del protocolo. 



Cuando se establece la conexion entre el cliente y el servidor, en un 
inicio se supone que la comunicacion se produce entre dos NVT. Elio 
significa que tanto el sistema cliente como el sistema servidor deben 
mapear sus caracterfsticas en las de un NVT y suponer que en el otro 
extremo de la conexion hay otro NVT. En el modo de operacion nor- 
mal, cada terminal acepta datos del usuario y los envfa por medio 
de la conexion establecida en el otro terminal, asf como acepta los 
datos que llegan por la conexion y se los presenta al usuario. 

Las caracterfsticas principales de los NVT son las siguientes: 

a) Los datos se intercambian en bytes de 8 bits. Cuando representan 
caracteres, se utiliza la codificacion ASCII (por tanto, se envfa un 
codigo de 7 bits en cada byte). 
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b) Existen tres caracteres de control que el NVT siempre los interpreta 
de la manera siguiente: 

• NUL (caracter de control nulo, codigo 0): no es necesario hacer 
nada. 

• LF (avance de Ifnea, codigo 1 0): mover la posicion de escritura 
actual (en una impresora, el carro, y en una pantalla, el cursor) 
una Ifnea adelante manteniendo la posicion horizontal. 

• CR (retorno de carro, codigo 13): mover la posicion de escri- 
tura atras hasta el principio de la Ifnea actual. 

Por tanto, un final de Ifnea (es decir, un salto al principio de la 
Ifnea siguiente) se podrfa representor con las secuencias CR- 
LF o LF-CR. Sin embargo, para facilitar el mapeo en terminales 
que no tienen funciones separadas para el avance de Ifnea y el 
retorno de carro, el protocolo Telnet especifica que los finales 
de Ifnea deben representarse con la secuencia CR-LF, y los re- 
tornos de carro sin mover la posicion vertical, con la secuencia 
CR-NUL . De este modo, cuando el terminal recibe un caracter 
CR, puede esperar a que llegue el siguiente, que debera ser LF 
o NUL, para saber que accion debe llevar a cabo. 

c) Hay cinco caracteres mas que opcionalmente pueden ser inter- 
pretados por el NVT y cuyo significado es el siguiente: 

• BEL (timbre, codigo 7): generar una serial que, por lo general, 
sera audible, pero que alternativamente puede ser visible, sin 
mover la posicion actual. 

• BS (retroceso, codigo 8): mover la posicion horizontal un es- 
pacio atras. 

• HT (tabulacion horizontal, codigo 9): mover la posicion hori- 
zontal hacia delante hasta la posicion de tabulacion siguiente. 

• VT (tabulacion vertical, codigo 11): mover la posicion vertical 
hacia delante hasta la posicion de tabulacion vertical siguiente. 

• FF (avance de pagina, codigo 12): mover la posicion vertical 
hasta el principio de la pagina siguiente, sin mover la posicion 
horizontal. 



195 



Cualquier otro caracter de control se considera equivalente a NUL. 



d) El dispositivo NVT es full duplex; sin embargo, por norma general 
trabaja en modo half duplex ; es decir, solo envfa los datos del 
usuario cuando ha lefdo una Ifnea completa o cuando recibe al- 
guna otra serial local que provoque la transmision. 

e) Si el usuario, de momento, no dispone de mas datos para enviar, 
y se han procesado todos los datos recibidos, el terminal puede 
transmitir al sistema remoto una serial, denominada Go Ahead 
(GA), para indicarle que es su turno de enviar datos. 



Nota 

Solo deberfa utilizarse la serial GA cuando el otro sistema 
no tuviera otra manera de saber que no debe esperar 
mas datos. Una situacion tfpica es que el usuario (cliente) 
genere Ifneas de una en una y el sistema remoto (servidor) 
envfe respuestas de cero, una o mas Ifneas a cada una. 
En este caso, solo sera necesario que el servidor envfe la 
serial GA para notificar que el control pasa al usuario del 
terminal, y no sera preciso que el cliente se lo envfe des- 
pues de cada Ifnea. 



Nota 



Veremos el signiticado de 
las funciones de control en 
el apartado 18 . 1 . 2 . 



f) El NVT tambien puede generar, a instancias del usuario, dos se- 
nales mas, denominadas Break (BRK) y Synch. El significado de la 
primera depende de la aplicacion. La segunda sirve para cance- 
lar los datos que haya enviado el terminal y todavfa no hayan sido 
procesados por el sistema remoto. 



g) Asimismo, existen cinco funciones de control que puede generar el 
NVT a instancias del usuario: Interrupt Process (IP), Abort Output 
(AO), Are You There (AYT), Erase Character (EC) y Erase Line (EL). 



el cliente y el servidor soportan una funcionalidad mas 
avanzada que la de un NVT, que es lo mas habitual, el 
protocolo permite que lleven a cabo una negociacion 
para ponerse de acuerdo sobre que caracterfsticas dife- 
rentes de las de un NVT utilizaran en la comunicacion. 
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La negociacion consiste en intercambiar codigos que indican las op- 
ciones del protocolo que cada parte desea o esta dispuesta a utilizar. 
Cuatro son los codigos que se utilizan para implementor la negocia- 
cion: 

• DO es una peticion que se envfa para pedir que se utilice una de- 
terminada opcion. 



Nota 



Las opciones Telnet posibles 
no estan detinidas en la es- 
pecificacion del protocolo, 
sino en especificaciones in- 
dependientes. 



• WILL es un ofrecimiento que se envfa para indicar que el sistema 
esta preparado para utilizar una determinada opcion. 



• DON' T significa que el sistema no quiere que se utilice la opcion 
indicada. 



• WON' T significa que el sistema no esta preparado para utilizar la 
opcion indicada. 



Nota 

El mecanismo de negociacion es simetrico, de manera 
que cualquiera de las dos partes puede enviar un DO 
o un WILL. Tras enviar un DO, puede recibirse un 
WILLcomo respuesta positiva o un WON' T como res- 
puesta negativa. Desde un punto de vista analogo, 
despues de enviar un WILL, se puede recibir un DO 
como respuesta positiva o un DON' T como respuesta 
negativa. Elio significa que un DO puede actuar como 
peticion o como confirmacion si la otra parte ha envia- 
do un WILL, y viceversa. 



Por norma general, la negociacion de las opciones se produce al ini- 
cio de la conexion, pero tambien es posible efectuarla en cualquier 
otro momento. Cada sistema debe empezar a utilizar una opcion 
cuando envfa o recibe la respuesta positiva correspondiente. 

Este mecanismo de negociacion esta disenado para que sea facil- 
mente extensible. Si un sistema no reconoce una determinada opcion 
que se le pide o se le ofrece, simplemente debe contestar con WON' T 
O DON' T. 
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Nota 



Muchas opciones definen 
sus comandos para la sub- 
negociacion, como IS (pa- 
ra enviar el valor de un 
parametro), SEND (para pe- 
dir que la otra parte lo en- 
vfe), etc. 



En ocasiones se necesita mas informacion para negociar una opcion, 
como el valor de algun parametro. En este caso, en primer lugar de- 
ben ponerse de acuerdo las dos partes con el mecanismo basico de 
los DO/ DON' T/WILL/WON' T para utilizar la opcion deseada y, una 
vez se haya aceptado, debe llevarse a cabo una subnegociacion de 
los valores de los parametros utilizando una sintaxis espedfica de 
cada opcion. 



17.1.2. Comandos del protocolo Telnet 

En los datos intercambiados entre dos sistemas que se comunican 
con el protocolo Telnet, se pueden intercalar ciertos comandos 
propios del protocolo, tales como la serial GA o los codigos de ne- 
gociacion. Para distinguir los comandos de los datos normales, 
los primeros deben ir prefijados con un codigo especial llamado 
IAC (Interpret As Command), que se representa con un byte igual 
a 255. 

Por consiguiente, cada comando se representa con una secuencia de 
dos bytes, en la que el primero es el codigo IAC, y el segundo, el co- 
digo propio del comando, excepto los comandos de negociacion, 
que disponen de un tercer byte que sirve para indicar a que opcion 
se refieren. Para representor un byte normal de datos que sea igual 
a 255, es preciso prefijarlo con un codigo IAC. Cualquier otro byte 
de datos se representa directamente con su codigo. 

Los comandos definidos en el protocolo Telnet son los siguientes: 

• NOP (No Operation, codigo 241): operacion nula. 

• GA (Go Ahead, codigo 249): serial GA 

• BRK (Break, codigo 243): serial BRK. 

• DO (codigo 253) + codigo opcion: codigo de negociacion DO. 

• DON' T (codigo 254) + codigo opcion: codigo de negociacion DON' T. 

• WILL (codigo 251 ) + codigo opcion: codigo de negociacion WILL. 

• WON' T (codigo 252) + codigo opcion: codigo de negociacion WON' T. 
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• SB ( Subnegotiation Begin, codigo 250) + codigo opcion: los datos 
que vengan a continuacion corresponden a la subnegociacion de 
una opcion. 

• SE ( Subnegotiation End , codigo 240): indica el fin de los datos de 
subnegociacion. 

• DM (Data Mark, codigo 242): indica en que punto de la secuencia 
de datos se ha enviado una serial Synch. 

• IP ( Interrupt Process, codigo 244): codigo de funcion que puede 
enviar el usuario para indicar al sistema remoto que interrumpa 
el proceso que esta ejecutando. 

• AO (Abort Output, codigo 245): codigo de funcion que sirve para 
indicar que se continue ejecutando el proceso remoto, pero que 
deje de enviar al usuario los datos que genera. 

• AYT (Are You There, codigo 246): codigo de funcion que pide al 
sistema que, cuando lo reciba, conteste con algun mensaje que 
sirva al usuario para verificar que la conexion continua estableci- 
da (por ejemplo, cuando el proceso que ejecuta tarda en generar 
una respuesta). 

• EC ( Erase Character, codigo 247): codigo de funcion que sirve 
para borrar el ultimo caracter escrito en el terminal. 

• EL ( Erase Line, codigo 248): codigo de funcion que sirve para bo- 
rrar toda la Ifnea actual. 

El protocolo Telnet tambien proporciona un mecanismo para trans- 
mitir la serial Synch. Esta ultima no se representa con un comando 
como los otros, dado que debe tener un efecto inmediato. En este ca- 
so, se envfan datos urgentes TCP acabados con un codigo DM y, en 
la secuencia de datos normales, se inserta otro codigo DM. Al recibir 
los datos urgentes, el sistema remoto pasara a procesar los datos 
normales en modo urgente (que puede consistiren descartar todo lo 
que haya en estos datos, salvo los comandos especiales) hasta que 
encuentre el DM. 

El terminal puede generar automaticamente una serial Synch cuando 
el usuario envia alguna de las funciones que requieren atencion in- 
mediata, como IP, AO o AYT (pero no EC o EL). 
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17.1.3. Implementaciones del protocolo Telnet 



Hay implementaciones de servidores Telnet practicamente en todos 
los sistemas multiusuario que utilizan el protocolo TCP. Los clientes 
Telnet son mas numerosos todavfa, porque tambien hay para siste- 
mas monousuario. 



Un ejemplo de implementacion de cliente Telnet es la utilidad del sis- 
tema operativo GNU/Linux denominada precisamente telnet. Si 
se llama sin argumentos, entra en modo comando. Con un argu- 
mento, que puede ser una direccion IP o un nombre de servidor, es- 
tablece una conexion con el puerto Telnet (el 23) de este servidor y 
entra en modo conexion. Con un segundo argumento, que puede ser 
un numero de puerto o un nombre de servicio, establece la conexion 
con este puerto. 

Cuando el numero de puerto utilizado es el 23, el cliente inicia auto- 
maticamente el proceso de negociacion enviando los codigos DO y 
WILL correspondientes a las opciones que soporta. Con cualquier 
otro puerto, por norma general no se envfa ningun codigo de nego- 
ciacion, salvo que se reciba alguno del sistema remoto. 



Cuando el programa esta en modo conexion, envfa al sistema remo- 
to cada caracter que teclea el usuario. Desde el modo conexion se 
puede pasar al modo comando por medio del caracter de escape, que 
suele ser " A ] ". En este modo, el programa admite, entre otros, los co- 
mandos siguientes: 



Nota 



Las nombres de los coman- 
dos se pueden abreviar 
siempre que la abreviatura 
no genere ambiguedades. 



open: establece una conexion con el servidor, y opcionalmente 
con el puerto, indicado en los argumentos de este comando. 



comando nulo (Ifnea vacfa): si hay una conexion establecida, sale 
del modo comando y vuelve al modo conexion. 



• send envfa al sistema remoto el codigo Telnet indicado por el argu- 
mento, que puede ser ao, ayt, brk, ec, el, ga, ip, synch, etc. 



" A ]" (o el caracter que actue como caracter de escape): envfa este 
ultimo al sistema remoto (equivale a send escape). 
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• ?: muestra un mensaje de ayuda. 

• quit: cierra la conexion, en caso de haber conexion establecida, 
y acaba el programa (que tambien acaba cuando el sistema re- 
moto cierra la conexion). 



Actividad 

Con algunas implementaciones Unix del cliente 
Telnet, se puede utilizar el comando toggle netdata 
para ver el dialogo de la negociacion. Probad esta 
otra opcion en una sesion interactiva (en el puerto por 
defecto 23) y en una conexion a otro puerto (por ejem- 
plo, echo). 



17.2. Terminal virtual en GNU/Linux: 
el protocolo rlogin 



Cuando se desea establecer una sesion de trabajo interactiva desde 
un sistema Unix con otro sistema Unix, ademas de utilizar el protocolo 
Telnet, tambien existe la posibilidad de utilizar el protocolo llamado 
rlogin. Este ultimo se desarrollo en un inicio en el entorno de las utili- 
dades de comunicaciones de la variante de Unix llamada BSD; sin em- 
bargo, hoy dfa hay implementaciones disponibles en todas las 
variantes, asf como en otros sistemas operativos. La especificacion del 
protocolo rlogin esta publicada en el documento RFC 1282. 



Las caracterfsticas principales que diferencian el protocolo rlogin del 

protocolo Telnet son las siguientes: 

a) El servidor siempre es informado del tipo de terminal con que tra- 
baja el cliente sin necesidad de negociacion. 

b) El servidor tambien es informado de la identidad del usuario en 
el sistema cliente, lo que se puede utilizar para automatizar el 
proceso de autenticacion. 

c) Si cambian los tamanos de la ventana de presentacion del termi- 
nal, se puede enviar automaticamente una serial al servidor para 
notificarselo. 



Lectura complementaria 



Para obtener mas informa- 
cion sobre el protocolo rlogin, 
consultad la obra siguiente: 
B. Kantor (1991, diciem- 
bre). RFC 1282 -BSD Rlogin. 
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d) En la transmision de datos, siempre pueden utilizarse los 8 bits de 
cada byte. 



17.2.1. Conceptos basicos del protocolo rloqin 

El protocolo rlogin utiliza conexiones TCP. El nombre oficial del ser- 
vicio proporcionado por este protocolo es login y el numero de 
puerto asignado a este servicio es el 51 3. 

Cuando el cliente establece la conexion con el servidor, en primer lu- 
gar le envla cuatro cadenas de caracteres, cada una acabada con un 
caracter NUL (codigo 0). Son las cadenas siguientes: 



• Una cadena vacfa (solo contiene el caracter NUL). 

• El nombre del usuario en el sistema cliente. 

• El nombre de usuario con que se quiere establecer la sesion de 
trabajo en el sistema servidor. 

• El tipo de terminal y, separado con "/", su velocidad (por ejem- 
plo, vtl 00/9600). 

Cuando ha recibido estas cuatro cadenas, el servidor envla un carac- 
ter NUL y empieza la transferencia de datos entre cliente y servidor 
en modo control de flu jo. En este modo, el cliente envla los caracteres 
que teclea el usuario tal como le llegan, excepto los caracteres de 
control DC3 (" A S") y DC1 (" A Q"), que significan 'suspender la trans- 
mision' y 'retomarla', respectivamente. 

Por otro lado, el cliente presenta los datos que envla el servidor tal 
como le llegan. El cliente tambien puede recibir mensajes de control 
del servidor, que se representan con un codigo de un byteenviado 
en datos urgentes TCP. El cliente debe responder a estos mensajes 
de manera inmediata y suspender temporalmente el procesado de 
otros datos que pueda haber recibido. 



17.2.2. Implementacion del protocolo rlogin 

En los sistemas GNU/Linux hay una utilidad llamada rlogin que ac- 
tua como cliente del protocolo rlogin. Es preciso que se le especifique 
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el nombre del servidor remoto y, de manera optativa, el nombre de 
usuario que debe utilizar en este servidor, con la opcion -1 (por defec- 
to, se utiliza el mismo nombre de usuario que en el sistema local). 

La mayorfa de los servidores rlogin implementan la autenticacion au- 
tomatica de la manera siguiente: 

• Si el usuario remoto tiene en su directorio un fichero llamado 
. rhosts con una Ifnea en la que se encuentre el nombre del or- 
denador cliente y, opcionalmente, el nombre del usuario cliente 
(en ausencia de este nombre de usuario, se toma el del usuario 
en el servidor), se inicia directamente la sesion interactive sin ne- 
cesidad de pedir ninguna contrasena. 

• Si no dispone de este fichero, se consulta otro, el /etc/ 
hosts . equiv, para ver si existe alguna Ifnea con el nombre del 
ordenador cliente (en este caso, debe coincidir el nombre del 
usuario en el cliente y en el servidor) y, si esta, tambien se da al 
usuario por autenticado. 

• En cualquier otro caso, se sigue el procedimiento normal de au- 
tenticacion mediante contrasena. 



Nota 

Por motivos de seguridad, los servidores rlogin suelen 
requerir que el fichero . rhosts tenga permiso de lec- 
tura solo para el usuario a quien pertenece. Por otro 
lado, los nombres de servidores en los ficheros 
.rhosts y /etc/hosts . equiv no pueden ser alias, 
deben ser los nombres oficiales. Y, como precaucion 
adicional, el fichero /etc/hosts . equiv solo se uti- 
liza cuando el nombre del usuario en el servidor es di- 
ferente de root. 



Antes de consultar los ficheros . rhosts y /etc/hosts . equiv, el 
servidor siempre comprueba que el cliente se haya conectado desde 
un puerto reservado (con numero inferior a 1 024). En caso contrario, 
no se permite la autenticacion automatica, puesto que la conexion 
podrfa provenir de otro usuario que estuviera ejecutando un progra- 
ma que siguiese el protocolo rlogin, pero que enviase informacion 
falsa sobre su identidad. 
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La autenticacion automatica puede resultar comoda porque ahorra 
teclear las contrasenas, pero tambien puede ser una fuente de pro- 
blemas si no se utiliza con precaucion. 

Ademas de leer los caracteres tecleados y enviarselos al servidor, 
el cliente tambien puede recibir comandos del usuario. Para dis- 
tinguirlos de los caracteres normales, se representan con un ca- 
racter precedido del sfmbolo Esta secuencia solo se reconoce 
al inicio de las Ifneas (es decir, inmediatamente a continuacion de 
un salto de Ifnea). El caracter del comando puede ser, por ejem- 
plo, el siguiente: 

• " A z" (o el caracter correspondiente a la funcion SUSP del termi- 
nal): suspende la ejecucion del programa cliente, con la posibili- 
dad de retomarla mas adelante (la manera de hacerlo puede 
depender del shell, pero por lo general es con el comando fg). 

• " A Y" (o el caracter correspondiente a la funcion DSUSP del termi- 
nal): suspende el envfo de datos al servidor y, por consiguiente, el 
teclado queda disponible para otros procesos; sin embargo, la re- 
cepcion continua (si se reciben nuevos datos, se mostraran cuan- 
do lleguen). 

• envia el caracter 

• " . ": cierra la conexion. 

Si el caracter no corresponde a ningun comando reconocido por el 
cliente, se envia al servidor tal como ha llegado, precedido por el ca- 
rdcter 



1 7.3. Otros servicios 



17.3.1. Ejecucion remota con autenticacion automatica: rsh 

Paralelamente al servicio de terminal virtual, que permite mantener 
una sesion de trabajo en un sistema remoto, en los sistemas Unix 

204 



BSD se desarrollo otro servicio que permite ejecutar un comando en 

el sistema remoto. El programa que actua como cliente de este ser- 
vicio se llama rsh ( remote shell). 

El nombre oficial de este servicio es shell, el protocolo de transpor- 

te utilizado es el TCP y el numero de puerto asignado es el 514. 

A continuacion presentamos los pasos que se siguen en este protocolo: 

1 ) El servidor comprueba que el cliente se haya conectado desde un 
puerto reservado. En caso contrario, cierra la conexion. 

2) El cliente envia al servidor una cadena acabada en NUL que con- 
vene un numero decimal: 

• Si es diferente de cero, se interpreta como un numero de puerto y el 
servidor establece en este puerto una conexion secundaria (esta se- 
gunda conexion se establece tambien desde un puerto reservado). 

• Si es cero, la misma conexion principal actua tambien como se- 
cundaria. 

3) El cliente envia tres cadenas mas acabadas en NUL con el nombre 
del usuario en el sistema servidor, el nombre en el sistema cliente 
y el comando a ejecutar. 

4) El servidor comprueba en los ficheros . rhosts y/o /etc/ 
hosts, equiv que el usuario este autorizado para la autentica- 
cion automatica. 

5) Si lo esta, el servidor envia un caracter NUL por la conexion se- 
cundaria; en caso contrario, cierra las conexiones. 

6) El servidor ejecuta el comando indicado con la identidad del usuario 
indicado. Los datos que escriba este comando por la salida estandar 
(stdout en la nomenclatura del lenguaje C) se enviaran por la co- 
nexion principal, y los que escriba por la salida de error (stderr), 
por la conexion secundaria. Las que envie el cliente serdn accesibles 
por la entrada estandar (stdin). 

7) Cuando acabe la ejecucion del comando, el servidor cerrara la co- 
nexion. 
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17.3.2. Ejecucion remota: rexec 



Con rsh, el usuario debe estar autorizado por medio de los ficheros 
. rhosts o / etc/hosts . equiv del sistema remoto para poder eje- 
cutar un comando en el mismo. Existe otro servicio muy parecido en que 
no se utiliza la autenticacion automatica, sino que siempre requiere que 
el usuario proporcione su contrasena en el sistema remoto. En algunos 
sistemas Unix, se encuentra disponible un programa llamado rexec que 
actua como cliente de este servicio. En otros, solo hay una funcion de la 
libreria estandar, rexec, que implementa el protocolo. 

El nombre oficial de este servicio es exec, el protocolo detransporte 
utilizado es el TCP y el numero de puerto asignado es el 51 2. 

Este protocolo es muy parecido al anterior: las unicas diferencias son 
que, en lugar de enviar el nombre del usuario, en el sistema cliente se 
envfa la contrasena del usuario en el sistema servidor (los ficheros 
. rhosts y /etc/hosts . equiv no se consultan) y que no es preci- 
so verificar que las conexiones provengan de puertos reservados. 



17.3.3. Servicios triviales 

La mayorta de los sistemas Unix y GNU/Linux proporcionan una 
serie de servicios denominados triviales, que se pueden utilizar 
para llevar a cabo pruebas de funcionamiento de los modulos que 
implementan los protocolos de transpose. Todos son accesibles 
por medio de TCP y UDP, y el numero de puerto utilizado en am- 
bos casos es el mismo. Algunos ejemplos de servicios triviales son 
los siguientes: 

• echo (puerto 7): retorna todos los bytes (en TCP) o datagramas 
(en UDP) que recibe (RFC 862). 

• discard (puerto 9): lee datos (bytes o datagramas), pero no 
hace nada mas (RFC 863). 

• chargen (puerto 19): en TCP, cuando se establece la conexion, 
el servidor empieza a enviar una secuencia de caracteres hasta 
que el cliente la cierra y, en UDP, cuando el servidor recibe un da- 
tagrama, responde con otro que contiene un nombre arbitrario 
de caracteres (RFC 864). 
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• daytime (puerto 1 3): cuando se establece la conexion, o se reci- 
be un datagrama, el servidor envfa la fecha y la hora actual en 
formato legible para los humanos (RFC 867). 

• time (puerto 37): cuando se establece la conexion, o se recibe un 
datagrama, el servidor envfa un numero de 4 bytes que represen- 
ta el numero de segundos transcurridos desde el 1 de enero de 
1 970 a las 0 horas GMT (RFC 868). 



Finger 

Name/Finger es otro ejemplo de servicio sencillo que permite obtener 
informacion de un usuario en un sistema remoto. La especificacion del 
protocolo para este servicio esta recogida en el documento RFC 742. 

El nombre oficial de este servicio es finger, el protocolo de transporte 
utilizado es el TCP y el numero de puerto asignado es el 79. 

El programa cliente se llama finger y, por norma general, admite ar- 
gumentos de la forma usuario, usuario@host o 0host: 

• En el primer caso, proporciona informacion sobre un usuario en 
el sistema local sin necesidad de utilizar ningun protocolo. 

• En el segundo, informa sobre un usuario de un sistema remoto. 

• En el tercero, normalmente ofrece una informacion resumida de 
los usuarios que estan actualmente conectados con sesiones inte- 
ractivas al sistema remoto. 

Cuando se establece la conexion, el cliente simplemente envfa una 
Ifnea al servidor acabada con CR-LF. En esta ultima se encuentra el 
nombre del usuario de quien se quiere obtener informacion. Si no hay 
ningun nombre, se entiende que la solicitud se refiere a todos los 
usuarios que esten conectados. 

El formato de la respuesta depende de la implementacion del servi- 
dor y puede incluir informacion como el nombre del usuario, su 
nombre real, cuando se conecto por ultima vez, cuando recibio o 
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leyo el correo por ultima vez, etc., y, si esta conectado actualmente, 
desde donde, en que terminal, cuanto tiempo hace que no hay acti- 
vidad en su terminal, etc. La informacion retornada normalmente es 
un subconjunto de todos estos campos; sin embargo, si la Ifnea de 
peticion empieza con los caracteres "/W", el servidor puede retornar 
informacion mas completa. 
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18. Transferencia de ficheros 



1 8.1 . FTP: protocolo de transferencia 
de ficheros 

Una de las primeras aplicaciones basicas desarrolladas en el entor- 
no de lo que despues serfa la red Internet fue la transferencia de fi- 
cheros entre diferentes sistemas. Al principio de los anos setenta ya 
se elaboraron las primeras especificaciones del protocolo mas utili- 
zado para esta finalidad, el FTP. Despues de algunas modificaciones 
y mejoras, la especificacion oficial del protocolo se publico en 1985 
en el documento RFC 959. 

El FTP se basa en el modelo cliente/servidor y permite la transferen- 
cia de ficheros tanto del servidor al cliente, como del cliente al servi- 

dor. Asimismo, permite que un cliente efectue transferencias directas 
de un servidor a otro, con lo que se ahorra la necesidad de copiar 
los ficheros del primer servidor al cliente y pasarlos despues del clien- 
te al segundo servidor. 

El protocolo proporciona tambien operaciones para que el cliente 
pueda manipular el sistema de ficheros del servidor: borrar ficheros 
o cambiarles el nombre, crear y borrar directories, listar sus conteni- 

dos, etc. 

Uno de los objetivos principales de este protocolo consiste en permitir 
la interoperabilidad entre sistemas muy distintos, escondiendo los 
detalles de la estructura interna de los sistemas de ficheros locales y 
de la organizacion de los contenidos de los ficheros. 



Nota 

Algunos de los sistemas utilizados en la epoca de 
desarrollo del FTP actualmente estan obsoletos; por 
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Lectura complementaria 



Para mas informacion sobre 
el FTP, consultad la obra si- 
guiente: 

J. Postel; J. Reynolds 

(1985, octubre). RFC 959 - 
File Transfer Protocol. 




ejemplo, los que utilizan palabras de 36 bits o codi- 
gos de caracteres incompatibles con el estandar AS- 
CII o los que almacenan los ficheros en "paginas" 
no necesariamente contiguas. De hecho, muchas de 
las implementaciones actuales del protocolo no so- 
portan estas caracterfsticas especiales previstas en 
la especificacion. 



18.1.1. El modelo del FTP 

En el modelo general descrito en la especificacion del FTP, tanto 
en el servidor como en el cliente hay dos entidades que intervie- 
nen en la transferencia de ficheros: 

a) El interprete de protocolo se encarga del intercambio de los 
comandos del protocolo. En la parte del cliente, las operacio- 
nes que el usuario solicita por medio de la interfaz de usuario, 
el interprete las convierte en una secuencia adecuada de co- 
mandos FTP y se envian al servidor. 



En la parte del servidor se interpretan los comandos recibidos, se 
generan las respuestas correspondientes y se envian al cliente. 
Por tanto, el interprete cliente debe analizar estas respuestas, por 
ejemplo, para informar al usuario del resultado de la operacion 
o para proseguir la secuencia de comandos FTP. 

b) El proceso de transferencia de datos, que esta bajo el control 
del interprete de protocolo, se encarga de intercambiar los da- 
tos que deben transferirse, es decir, los contenidos de los fiche- 
ros o bien los listados de los directories. 
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Tanto en la parte del cliente, como en la del servidor este pro- 
ceso interactua directamente con el sistema de ficheros locales 
para leer sus datos o para almacenarlos en los mismos. 




Los dos interpretes de protocolo se comunican mediante una conexion 
TCP llamada conexion de control. Cuando deben transferirse datos de 
un sistema al otro, se establece otra conexion TCP entre los dos procesos 
de transferencia de datos denominada conexion de datos. Generalmen- 
te, la parte activa de esta conexion (la que la inicia) constituye el proceso 
de transferencia del servidor, y la parte pasiva, el del cliente. 

La figura siguiente muestra la variacion del modelo general para 
el caso en que un cliente controle una transferencia entre dos ser- 
vidores (uno de los cuales actuara como servidor activo y el otro, 
como servidor pasivo): 



Nota 



El FTP permite efectuar mas 
de una transferencia en una 
unica sesion. Segun el modo 
de transmision, es posible 
que se abran y se cierren di- 
ferentes conexiones de datos 
durante una misma co- 
nexion de control, o bien que 
se utilice la misma conexion 
de datos para las diferentes 
transferencias. 
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18.1.2. Conceptos basicos del FTP 



El FTP esta basado en conexiones TCP. El interprete de protocolo del 
servidor debe estar preparado para recibir peticiones de conexion en 
un puerto TCP que, por defecto, es el asignado oficialmente al servi- 
cio FTP: el numero 21 . 



Nota 



Consultad la descripcion de 
las reglas especiticadas por 
el protocolo Telnet (RFC 
854) en el apartado 18.1 de 
la unidad anterior. 



El interprete de protocolo del cliente establece una conexion de con- 
trol con el puerto del interprete servidor. En esta conexion se utilizan 
las reglas especificadas en el protocolo Telnet. Elio significa que, por 
defecto, los interpretes de protocolo se intercambian mensajes codi- 
ficados con bytes de 8 bits, segun el juego de caracteres ASCII, y re- 
presentan los finales de linea con la secuencia <CRLF>. 



Nota 



Las excepciones a la regia 
de la respuesta secuencial 
son los comandos obtener 
el estado actual de una 
transferencia, abortar una 
operacion y cerrar la sesion. 



Los comandos FTP constituyen los mensajes que envia el interprete 
cliente, y los que envia el interprete servidor son respuestas a dichos 
comandos. Las respuestas se generan siguiendo el orden en que el 
cliente envia los comandos, puesto que en general el servidor efectua 
las operaciones de manera secuencial (no empieza una nueva ope- 
racion hasta que no ha acabado la anterior). A continuacion, anali- 
zamos por separado los comandos y las respuestas: 



1 ) Comandos FTP: un comando FTP se representa por medio de un 
codigo de comando de hasta cuatro letras (que pueden ser indis- 
tintamente mayusculas o minusculas), seguido de una lista de 
cero o mas argumentos, separados por espacios, acabada con un 
final de linea. 



Nota 



Algunas implementaciones 
de servidores FTP soportan 
otros codigos de comandos 
no estandares, que pueden 
tener mas de cuatro letras. 



La especificacion RFC 959 define treinta y tres comandos agrupados 
en tres categorias diferentes (representamos entre parentesis el codi- 
go correspondiente a cada comando): 

a) Comandos de control de acceso: nombre de usuario (USER), 
contrasena (PASS), cuenta ^LCCT), cambiar de directorio (SWD), 
cambiar al directorio padre (CDUP), montar un sistema de ficheros 
(SMNT), reinicializar (REIN), acabar la sesion (QUIT). 

b) Comandos de parametros de transferencia: estructura de fiche- 
ro (STRU), modo de transmision (MODE), tipo de representacion 
(TYPE), puerto de datos (PORT), puerto pasivo (PASV). 
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c) Comandos de servicio FTP: obtener (RETR), almacenar (STOR), 
almacenar con nombre unico (STOU), anadir (APPE), listar 
(LIST), listar nombres (NLST), mostrar el directorio actual (PWD), 
reservar espacio (ALLO), abortar (M30R), retomar (REST), borrar 
(DELE), nombre antiguo (RNFR), nombre nuevo (RNTO), crear un 
directorio (MKD), borrar un directorio (RMD), estatus (STAT), siste- 
ma (SYST), servicios adicionales (SITE), ayuda (HELP) y opera- 
cion nula (NOOP). 

2) Respuestas FTP: las respuestas constan de un codigo numerico 
de tres digitos decimoles, que permite al interprete del protocolo 
cliente saber cual es el resultado de la operacion, seguido de un 
texto explicativo destinado al usuario humano. 



Nota 



De este grupo de comandos 
de servicio, los seis siguien- 
tes son los comandos de 
transferencia; es decir, los 
que utilizan la conexion de 
datos. 

- RETR 

- STOR 

- STOU 

- APPE 

- LIST 

- NLST 



El texto explicativo del mensaje de respuesta puede tener una Ifnea o 
mas: 



• Si tiene una Ifnea, la respuesta se representa con el codigo nume- 
rico seguido del caracter espacio y, a continuacion, el texto y un 
final de Ifnea. 

• Si tiene mas de una Ifnea, la primera se representa con el codigo 
numerico seguido del caracter y, a continuacion, las Ifneas de 
texto, acabadas con finales de Ifnea, la ultima de las cuales debe 
empezar con el mismo codigo numerico de la primera Ifnea se- 
guido del caracter espacio. 



Ejemplo 

Ejemplo de respuesta de una sola Ifnea: 

220 Sistema preparado. Introducid nombre de 

usuario y contrasena. 

Ejemplo de respuesta con multiples Ifneas: 

220-Sistema preparado. 

Introducid el nombre de usuario y la 
contrasena para acceder a los ficheros 
restringidos , o utilizad el nombre 
"anonymous " 

220 para acceder al directorio publico. 
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Nota 



La estructura de los codigos 
de respuesta y el significado 
de cada digito son comunes 
a todos los protocolos. Po- 
deis encontrar una explica- 
cion de los mismos en el 
anexo 4. 



La especificacion RFC 959 define los codigos de respuesta posibles 
para cada uno de los comandos y su significado. 



Tabla 8. 



Codigos de respuesta 


Codigo 


Significado 


1 10 


Marca de reanudacion. 


120 


Esperar hasta que el servidor este preparado. 


125 


El servidor transfiere datos (la conexion de datos ya esta abierta). 


150 


El servidor establece la conexion de datos e inicia la 
transferencia. 


200 


Operacion efectuada. 


202 


Comando innecesario en este servidor. 


21 1 


Informacion de estado del sistema o mensaje de ayuda del 
sistema. 


212 


Informacion de estado del directorio. 


213 


Informacion de estado del fichero. 


214 


Mensaje de ayuda (destinado al usuario humano). 


215 


Tipo de sistema. 


220 


Servidor preparado. 


221 


El servidor cierra la conexion de control. 


226 


Operacion efectuada y conexion de datos cerrada. 


227 


El servidor esta en modo pasivo (hi ,h2 ,h3 ,h4 ,pl ,p2). 


230 


Proceso de autenticacion completado satisfactoriamente. 


250 


Operacion de fichero efectuada. 


257 


El directorio es el resultado de la operacion. 


331 


Enviar contrasena. 


332 


Enviar cuenta. 


350 


Enviar el comando siguiente para completar la operacion. 


421 


Servicio no disponible (por ejemplo, por time out...), conexion de 
control cerrada. 


425 


No se puede establecer la conexion de datos. 


426 


Transferencia abortada y conexion de datos cerrada. 


450 


No se puede efectuar la operacion sobre el fichero (por ejemplo, 
fichero ocupado). 


452 


Espacio de disco insuficiente: transferencia no iniciada. 


500 


Error de sintaxis en el comando. 
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Codigos de respuesta 



Codigo 


Significado 


501 


Error en los argumentos. 


502 


Comando no implementado. 


503 


Error en la secuencia de comandos (este comando no 
corresponde). 


504 


Argumento no soportado. 


530 


El usuario no se ha autenticado correctamente. 


532 


Se necesita cuenta para esta operacion. 


550 


No se puede acceder al fichero o directorio (no existe, acceso 
denegado, etc.). 


552 


Espacio de disco insuficiente: transferencia abortada. 


553 


Nombre de fichero no permitido. 



Cuando ha establecido la conexion de control con el interprete de pro- 
tocolo del servidor y antes de enviar ningun comando, el cliente debe 
esperar a recibir una respuesta, que puede tener los codigos 220, 421 
6 1 20. Si el codigo es 1 20, el cliente debe esperar hasta que el servidor 
envfe una respuesta 220. Cuando el servidor indique que esta prepara- 
do, puede empezar el intercambio de comandos y respuestas. Por nor- 
ma general, el servidor cerrara la conexion de control cuando se lo 
solicite el cliente (con el comando de acabar sesion). 



Nota 



El texto explicativo de las 
respuestas es de formato li- 
bre, excepto en el caso de 
las respuestas 1 10 (coman- 
do RETR), 227 (comando 
PASV) y 257 (comandos 
PWD y MKD). 



Si el cliente desea realizaroperaciones de transferencia, su proceso 
de transferencia de datos deberfa estar preparado para recibir peti- 
ciones de conexion en un puerto TCP, que por defecto es el mismo 
desde el que el interprete ha iniciado la conexion de control. 

El encargado de establecer las conexiones de datos es el proceso 
de transferencia de datos del servidor, desde su puerto de datos. 

Por defecto, este puerto es L - 1 (donde L es el numero de puerto 
correspondiente a la conexion de control). Es decir, si el servidor ha 
recibido la conexion de control en el puerto 21, su puerto de datos 
por defecto sera el 20. Evidentemente, el cliente puede solicitor el uso 
de puertos diferentes de los predeterminados por medio de los co- 
mandos adecuados. 

Generalmente, las conexiones de datos las cierra el servidor, excepto 
cuando sea la otra parte (el cliente o un servidor pasivo) quien envfe 
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los datos y el modo de transmision utilizado requiera el cierre de la 
conexion para indicar el final del fichero. 



18.1.3. Funeionalidad del FTP 

Las acciones que lleva a cabo el servidor para cada uno de los co- 
mandos definidos en la especificacion RFC 959 son los siguientes: 

1 ) Nombre de usuario (USER) 

El argumento de este comando es el nombre que es preciso sumi- 
nistrar al sistema servidor para identificar al usuario con el obje- 
tivo de acceder a los ficheros. Este suele ser el primer comando 
que envia el cliente. Asimismo, es posible enviarlo en medio de 
una sesion; entonces el servidor se olvida de la identidad del 
usuario anterior y realiza las nuevas operaciones bajo el nombre 
del nuevo usuario. 

Si el servidor envia la respuesta 230, significa que el proceso de au- 
tenticacion ya se ha completado; si envia la 530, significa que este 
usuario no es admisible (por ejemplo, porque no hay ningun ususa- 
rio con este nombre) y, si envia la 331 o la 332, entonces se necesita 
una contrasena o una cuenta, respectivamente. 



Not a 

En muchos sistemas, un intento de conexion con un 
nombre de usuario inexistente dara como resultado 
una respuesta 331 , para no proporcionar informacion 
a los usuarios ajenos al sistema sobre que nombres 
son validos y cuales no. 

El codigo 332 indica que la operacion solicitada se lleva- 
ra a cabo tan pronto como se reciba el comando ACCT . 



2) Contrasena (PASS) 

El argumento de este comando es la contrasena que necesita el sis- 
tema servidor para verificar la identidad del usuario. Si no se necesita 
ninguna, la respuesta sera 202; si se necesita pero es incorrecta, 
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530, y si es correcta, puede ser 230 (autenticacion completada) o 
332 (se necesita una cuenta). 

3) Cuenta (ACCT) 



Algunos sistemas pueden requerir que el usuario proporcione una 
identificacion de cuenta, bien en el proceso de autenticacion inicial, 
bien para efectuar determinadas operaciones, como almacenar fi- 
cheros. El servidor hara saber que necesita esta informacion envian- 
do una respuesta 332 en el proceso de autenticacion, o una 
respuesta 332 o 532 despues de una determinada operacion. 

4) Estructura de fichero (STRU) 



Este comando sirve para especificar como estaran estructurados los 
ficheros que deben transferirse. El tipo de estructura afecta al modo 
de transmision, como veremos a continuacion. Los valores posibles 
del argumento son los tres siguientes: 



• R: el fichero consta de una secuencia de registros. 

• P: la estructura se basa en paginas indexadas. (La opcion P era 
util en los sistemas de la epoca en que se desarrollo el FTP; hoy 
dia esta practicamente en desuso.) 

• F: el fichero se considera simplemente una secuencia de bytes (en 
este caso se considera que solo hay estructura de fichero). 

Si no se utiliza el comando STRU, el tipo de estructura por defecto es F. 

5) Modo de transmision (MODE) 

El argumento indica como se transmitiran los ficheros. Puede tener 

los valores siguientes: 

• B: la transmision se Neva a cabo en bloques de datos, cada uno 
precedido de una cabecera con la longitud del bloque (2 bytes) y 
un codigo descriptor (1 byte). Este ultimo sirve para indicar, por 
ejemplo, si el bloque es el ultimo de un registro o del fichero. 
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C: la transmision se realiza en bloques mas compactos, con cabe- 
ceras de un solo byte, y permiten codificar una secuencia de hasta 
64 bytes repetidos en un bloque de 2 bytes. 



Nota 



La combinacion modo 
stream y estructura de fiche- 
ro es la unica que requiere 
cerrar la conexion de datos 
despues de cada transferen- 
cia. En los otros casos, el 
servidor puede optar entre 
mantenerla abierta o ce- 
rrarla, e informa de la mis- 
ma al cliente con una 
respuesta 250 o 226, res- 
pective mente. 



• S: la transmision se efectua en modo stream; es decir, como 
una simple secuencia de bytes. Si se utiliza con el tipo de es- 
tructura en registros, se insertan codigos de control en la se- 
cuencia para senalar los finales de registro y de fichero. Si el 
tipo de estructura es de fichero y la transmision es en modo 
stream, la unica manera de indicar el final de fichero es cerran- 
do la conexion de datos. 

Si no se utiliza el comando MODE, el modo de transmision por defecto 
es S. 



6) Tipo de representacion (TYPE) 



Con este comando, se especifica como se representaran los datos 
de los ficheros que deben transferirse. El proceso que los envfa 
debe convertir el contenido de los ficheros en la representacion es- 
pecificada, y el proceso que los recibe, debe convertirlos en su re- 
presentacion local. Los valores posibles del argumento son los 
siguientes: 



• A: se utiliza la especificacion NVT definida en el protocolo Telnet 
(caracteres de 8 bits codificados en ASCII y finales de Ifnea repre- 
sentados con la secuencia <CRLF>). 



• E: se utilizan caracteres de 8 bits codificados en EBCDIC. 



Nota 

En los tipos de representacion A y E, un segundo ar- 
gumento opcional permite indicar como se especifi- 
ca la informacion de control para el formato vertical 
del texto (separacion entre parrafos, cambios de pa- 
gina, etc.) y puede valer N (no hay informacion de 
formato), T (hay caracteres de control Telnet: AS- 
Cl l\E BCDIC) o C (se utiliza el formato del estandar 
ASA, RFC 740). 
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• I: se envfa una imagen del fichero consistente en una secuencia 
arbitraria de bits, codificados en bytes (8 bits), que el receptor 
debe almacenar tal como le llega (o anadiendo ceros al final si el 
sistema local necesita que la longitud total sea multiplo de alguna 
cantidad). 



• L: se envfa una secuencia de bytes logicos de n bits, siendo n el 
valor del segundo argumento (obligatorio en este caso), con to- 
dos los bits consecutivos agrupados en bytes de 8 bits. Segun el 
valor de n, es posible que el receptor necesite aplicar alguna 
transformacion (reversible) para almacenar los datos. 



Nota 



Sea cual sea el tipo de re- 
presentacion, la transferen- 
cia siempre se realiza en 
bytes de 8 bits. 



Si no se utiliza el comando TYPE, el tipo de representacion por de- 
fecto es A (y sin informacion de formato vertical). 



7) Cambiar de directorio (CWD) 



Normalmente, cada usuario tiene asignado un directorio por defec- 
to en el sistema de ficheros del servidor. Este comando sirve para 
cambiar el directorio de trabajo por el directorio que indica el ar- 
gumento. 



8) Cambiar al directorio padre (CDUP) 

Este comando no recibe ningun argumento. Se trata de un caso par- 
ticular del anterior que el protocolo proporciona para facilitar el ac- 
ceso al directorio padre del actual con independencia de la sintaxis 
utilizada en el sistema de ficheros para referenciarlo. 

9) Montar un sistema de ficheros (SMNT)) 



El argumento es un nombre que, en la sintaxis del sistema de ficheros 
del servidor, permite seleccionar un nuevo grupo de ficheros (por ejem- 
plo, otro sistema de ficheros, otra particion del disco, otro disco, etc.). 

10) Mostrar el directorio actual (PWD) 



En la respuesta a este comando (codigo 257), el servidor informa 
del directorio actual. Para facilitar la interpretacion de la respues- 
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ta, el nombre del directorio debe ser la primera palabra que ven- 
ga despues del codigo numerico, y debe ir delimitado por el 
caracter 



11) Puerto de datos ((PORT) 



Nota 



Recordad que el puerto de 
datos por defecto del cliente 
es el mismo desde el que ha 
establecido la conexion de 
control. 



Con este comando, el cliente indica cual es su puerto de datos, en 
caso de que sea diferente del puerto por defecto. Para efectuar las 
transferencias, el servidor debera establecer la conexion de datos en 
el puerto especificado. Si ya habfa una conexion de datos establecida 
con otro puerto cuando se recibe este comando, el servidor debera 
cerrarla. 



El argumento debe tener esta forma: hi, h2, h3 , h4 , pi , p2 (cada 
uno de los elementos es un numero decimal entre 0 y 255). Los cua- 
tro primeros numeros forman la direccion IP, y los dos ultimos, el nu- 
mero de puerto (que se representa de mas a menos peso). 



Nota 

Cambio de puerto 

Cuando el modo de transmision requiere cerrar la co- 
nexion despues de cada transferencia, se suele utilizar 
este comando para ir variando el numero de puerto y 
evitar asf las demoras que puede haber cuando se in- 
tenta reutilizar un puerto TCP que se acaba de cerrar. 



Nota 



Consultad la figura mencio- 
nada en el apartado 18 . 1 . 1 . 



El cliente puede especificar una direccion IP diferente de la suya; de 
esta manera, se puede efectuar una transferencia entre dos servido- 
res, como ilustra la figura del modelo FTP, en que un cliente controla 
la transferencia de datos entre dos servidores. 



1 2) Puerto pasivo (PASV) 

Este comando sirve para indicar al servidor que, cuando se le envfe un 
comando de transferencia, en lugar de establecer de manera activa la 
conexion de datos, debe quedar preparado para recibirla de manera 
pasiva. En la respuesta (codigo 227), el servidor devuelve la direccion en 
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que esperard las peticiones de conexion, y utilizara la misma notacion 
del argumento del comando PORT. 



El comando PASV se utiliza en las transferencias entre servidores. 
El cliente debe establecer conexiones de control con los dos servi- 
dores, enviar un comando PASV a uno de los mismos y pasar la 
direccion devuelta al otro con un comando PORT. Entonces debe 
enviar el comando de transferencia correspondiente (leer o alma- 
cenar) al servidor pasivo, y el comando complementario al activo. 



1 3) Reservar espacio (ALLO) 



Algunos sistemas pueden requerir que se especifique la longitud 
de un fichero antes de almacenarlo. El argumento constituye el 
numero de bytes logicos a reservar. Si es necesario, el primer ar- 
gumento puede ir seguido de la cadena R n, donde n indica la 
longitud maxima de los registros o paginas (para ficheros con tipo 
de estructura R o P). 



Nota 



Recordad que cada byte 16- 
gico tiene n bits, donde n es 
el argumento del comando 
TYPE L o, por defecto, 8. 



14) Obtener (RETR)) 

Esta es la operacion de transferencia de ficheros del servidor hacia 
el cliente (o hacia el servidor pasivo). El argumento es el nombre del 
fichero que debe transferirse. 

Tanto en esta operacion como en las de almacenar y anadir, si el modo 
de transmision es B o C, el proceso que envia los datos puede insertar 
un tipo especial de bloque denominado marca de reanudacion (su con- 
tenido es un identificador de la posicion actual del fichero), que debera 
utilizarse en caso de error de la transferencia. Cuando encuentra la 
marca, el receptor asocia a la posicion actual un identificador propio y 
se lo notifica al usuario. Si quien actua de receptor es el servidor, activo 
o pasivo, la notificacion se lleva a cabo por medio de una respuesta con 
el codigo 1 10 y el texto MARK c = s. (c y s son los identificadores 
de la posicion del cliente y del servidor, respectivamente). 

15) Almacenar (STOR)) 

Esta es la operacion de transferencia de ficheros del cliente hacia el 
servidor. El argumento es el nombre del fichero en que el servidor 




debe almacenar los datos. Si este fichero no existe, se crea; si ya exis- 
te, se descarta su contenido y se sustituye por los datos recibidos. 



16) Almacenar con nombre unico (STOU) 

Esta operacion es como la anterior, pero sin argumento: el servidor 
elegira un nombre para el fichero (en el directorio actual) que no co- 
incida con ninguno de los ya existentes. En la respuesta debe notifi- 
carse el nombre elegido. 



1 7) Anadir (APPE) 

Esta operacion tambien es como la de almacenar, excepto que, si el fi- 
chero ya existe, los datos recibidos se anadiran al final de su contenido. 

1 8) Listar (LIST) 

El argumento de este comando es opcional. Si no hay argumento, el 
servidor envta por la conexion de datos una lista de los ficheros del 
directorio actual y sus atributos, por lo general en un formato propio 
del sistema. Si hay argumento, la lista se refiere al fichero o grupo de 
ficheros especificado, o a los ficheros contenidos en el directorio es- 
pecificado. 

1 9) Listar nombres (NLST) 



Nota 



Como precaucion, el cliente 
se deberia asegurar que el 
tipo de representacion es A 
o E antes de enviar el co- 
mando LISTo NLST. 



Este comando es como el anterior, pero con el formato de la lista 
normalizado, lo que significa que consta solo de los nombres de los 
ficheros, separados por finales de Ifnea, que permite que la lista de- 
vuelta sea procesada, por ejemplo, para que el cliente pueda imple- 
mentor una operacion para obtener un grupo de ficheros. 



20) Abortar (ABOR) 



Este comando hace que el servidor interrumpa la transferencia en 
curso (si hay) y, despues, cierre la conexion de datos. Si no, simple- 
mente cierra la conexion de datos. En el primer caso, el servidor en- 
vfa un codigo 426 como respuesta al comando de transferencia y, a 
continuacion, un codigo 226 en respuesta al comando ABOR En el 
segundo caso, solo envia la respuesta 226. 
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Nota 



Para indicar que el servidor debe atender un co- 
mando (ABOR, STAT, QUIT) mientras se este llevan- 
do a cabo una transferencia, la especificacion RFC 
959 sugiere que el cliente envie para la conexion de 
control el codigo de funcion IP del protocolo Telnet, 
seguido de una serial synch (es decir, un envio de 
datos urgentes TCP combinado con el codigo DM), 
y a continuacion el comando FTP. 



21) Retomar (REST)) 



Si una transferencia ha sido interrumpida por cualquier causa (caida del 
servidor, del cliente, de la red, etc.) es posible retomarla a partir de un 
punto indicado por una marca de reanudacion. El cliente debe enviar el 
comando REST con un argumento igual que el identificador de posicion 
del servidor correspondiente a la marca deseada e, inmediatamente a 
continuacion, el comando de transferencia que desea retomar. 



Nota 



Recordad que solo puede 
haber marcas de reanuda- 
cion en los modos de trans- 
mision B o C. 



22) Borrar (DELE) 



El efecto de este comando es borrar el fichero especificado en el ar- 
gumento. 



23) Nombre antiguo (RNFR) 



Para cambiar el nombre de un fichero, en primer lugar el cliente 
debe enviar este comando, con el nombre actual en el argumento e, 
inmediatamente, el comando RNTO. 



24) Nombre nuevo (RNTO) 

El argumento de este comando es el nombre nuevo que se debe con- 
ferir al fichero. Solo se puede utilizar inmediatamente a continuacion 
de un comando RNFR. 



25) Crear un directorio (MKD) 



El servidor crea el directorio indicado por el argumento. Si la opera- 
cion tiene exito, el formato del codigo de respuesta (codigo 257) es 
identico al del comando PWD. 
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Nota 

Segun la especificacion RFC 959, el nombre retornado 
en la respuesta 257 debe ser apto para poderlo utili- 
zar como argumento del comando CWD (cambiar di- 
rectorio). Como en algunos sistemas (obsoletos) este 
argumento no podia ser un nombre relativo al direc- 
torio actual, sino que debfa ser un nombre absoluto (y 
el del comando MKD, en cambio, sf que podia ser re- 
lativo), por norma general los servidores responden al 
comando MKD con el nombre completo del directorio 
creado. 



26) Borrar un directorio (RMD) 



El servidor borra el directorio indicado por el argumento. 



27) Estatus ((STAT) 

Si se envia este comando durante una transferencia, el servidor incluye 
en la respuesta informacion sobre el estado actual de la transferencia. 
Si no, se le puede pasar un nombre de fichero como argumento para 
que el servidor envfe informacion similar a la del comando LIST, pero 
por la conexion de control, o bien se puede utilizar sin argumento para 
obtener informacion general sobre el proceso FTP. 

28) Sistema (SYST) 



Nota 



La IANA (Internet Assigned 
Numbers Authority) es la 
encargada de publicar la 
lista de numeros asignados. 
En el momento de elaborar 
esta unidad, la ultima ver- 
sion de la lista se puede en- 
contrar en la especificacion 
RFC 1 700. 

ftp://ftp.isi.edu/in-notes/ 

iana/assignments/ 



El servidor envfa una respuesta informando sobre que tipo de siste- 
ma es. La primera palabra del texto debe ser uno de los nombres de 
sistema normalizados de la lista oficial de numeros asignados. 



Ejemplo 

Un cliente Unix puede utilizar este comando para saber 
si el servidor tambien es Unix y, si lo es, invocar auto- 
maticamente el comando TYPE I para mejorar la efi- 
ciencia de las transmisiones. 
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29) Servicios adicionales (SITE) 



Si el servidor ofrece servicios adicionales ademas de las operaciones es- 
tandar del protocolo, el cliente puede invocarlos por medio de los argu- 
mentos del comando SITE, cuya sintaxis depende del mismo servidor. 

30) Ayuda (HELP) 

Este comando, mediante el cual el servidor envla informacion general 
sobre la implementacion del protocolo (por ejemplo, que comandos so- 
porta y cuales no), se puede utilizar sin argumentos. No obstante, el ser- 
vidor tambien puede proporcionar informacion mas especffica si se le 
pasan argumentos (por ejemplo, un nombre de comando). 

31) Operacion nula (NOOP) 

El servidor simplemente envla una respuesta 200. 

32) Reinicializar (REIN) 

El servidor reinicializa la sesion olvidando la identidad del usuario y 
volviendo a dar a los parametros de transmision los valores por de- 
fecto. La sesion queda en el mismo estado en que se encontraba jus- 
to despues de establecer la conexion de control. 

33) Acabar la sesion (QUIT) 

El servidor da la sesion por finalizada y cierra la conexion de control 
(si hay una transferencia en curso, despues de enviar la respuesta co- 
rrespondiente). 

La tabla siguiente resume la sintaxis de los comandos y los posibles 
codigos de respuesta a cada uno de los mismos segun la especifica- 
cion RFC 959: 



Tabla 9. 



Sintaxis de los comandos y codigos de respuesta 


Comando 


Respuesta 


E s table cimien to 
de conexion 


220, 120, 421 


USER usuario 


230, 331, 332, 530 
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Sintaxis de los comandos y codigos de respuesta 



Comando 


Respuesta 


PASS contraseha 


230, 202, 332, 530 


ACCT cuenta 


230, 202, 530 


STRU F | R | P 


200, 504 


MODE S | B | C 


200, 504 


TYPE A | E | I | L 
[NITICI n] 


200, 504 


CWD directorio 


250, 550 


CDUP 


250, 550 


SMNT sist-ficheros 


250, 202, 550 


PWD 


257,550 


PORT 

hi , h2, h3 , h4, pl,p2 


200 


PASV 


227 


ALLO long-1 
[R long-2 ] 


200, 202, 504 


RETR fichero 


226, 250, 1 10, 125, 150, 550 


STOR fichero 


226, 250, 11 0, 1 25, 1 50, 452, 532, 552, 
553 


STOU 


226, 250, 1 1 0, 1 25, 1 50, 452, 532, 552, 
553 


APPE fichero 


226, 250, 1 1 0, 1 25, 1 50, 452, 532, 550, 
552, 553 


LIST [nombre] 


226, 250, 125, 150 


NLST [nombre] 


226, 250, 125, 150 


ABOR 


226 


REST marca 


350 


DELE fichero 


250, 550 


RNFR fichero 


350, 450, 550 


RNTO fichero 


250, 503, 532, 553 


MKD directorio 


257, 550 


RMD directorio 


250, 550 


STAT [nombre] 


211,212, 213 


SYST 


215 


SITE cadena. . . 


200, 202 


HELP [cadena] 


21 1, 214 


NOOP 


200 


REIN 


220, 120, 421 


QUIT 


221 
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Ademas de los codigos de respuesta espedficos contenidos en esta 
tabla, el cliente tambien puede redbir codigos de respuesta genera- 
les a cada comando, como 500, 501 , 502, 530 y 421 , o bien, en el 
caso de los comandos de transferencia, 425, 426 y 450. 



18.1.4. Implementaciones del FTP 



Nota 



La respuesta 502 solo es va- 
lida para los comandos no 
basicos; es decir, los que no 
pertenecen al grupo de la 
"implementacion minima" 



A la hora de implementor el protocolo FTP, debemos distinguir ser- 
vidor de cliente: 



1 ) Servidores FTP 



Segun la especificacion RFC 959, la implementacion minima de un 
servidor FTP debe soportar los comandos siguientes: 



• USER 

• RETR 

• TYPE A N 

• NOOP 

• STOR 

• MODE S 

• QUIT 

• PORT 

• STRU F 

• STRU R 



Nota 

Muchos servidores soportan el acceso publico (posible- 
mente restringido) a una parte de su sistema de ficheros 
sin necesidad de seguir el procedimiento normal de au- 
tenticacion. 



Este tipo de servicio se conoce como FTP anonimo. Por 
norma general, se accede al mismo utilizando el nom- 
bre de usuario anonymous como argumento del co- 
mando USER. Si el servidor pide una contrasena, 
suele aceptar cualquier cadena. En este caso, es cos- 
tumbre proporcionar la direccion de correo electroni- 
co del usuario como contrasena. 
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2) Clientes FTP 



En la actualidad, existen muchas implementaciones de clientes FTP 
para una gran variedad de sistemas diferentes (incluyendo los nave- 
gadores WWW); sin embargo, el cliente mas utilizado durante mu- 
cho tiempo ha sido la utilidad del sistema operativo Unix y de las 
distribuciones GNU/Linux denominada precisamente ftp. 

Este cliente presenta al usuario la mayorfa de las respuestas del ser- 
vidor, incluyendo los codigos numericos. Los principales comandos 
que ofrece son los siguientes: 



Nota 



Recordad que los nombres 
de los comandos se pueden 
abreviar siempre que no ge- 
neren ambiguedades. 



• open: permite especificar el nombre del servidor al que es preciso 
conectarse, si no se ha pasado como argumento del programa, y 
entonces pide automaticamente el nombre de usuario y, si prece- 
de, la contrasena. 

• cd, pwd, dir: envfan los comandos CWD, PWD y LIST al servidor. 

• ascii, binary: envfan los comandos TYPE A y TYPE I al servidor. 

• get: efectua la secuencia PORT-RETR para copiar un fichero del 
servidor. 

• put: efectua la secuencia PORT-STOR para copiar un fichero en 
el servidor. 

• A C (o el caracter que genere la serial de interrupcion): envfa el co- 
mando ABOR. 

• delete, mkdir, rmdir: envfan los comandos DELE, MKD y 
RMD. 

• rename: envfa la secuencia RNFR-RNTO necesaria para cambiar 
el nombre de un fichero. 

• mget: envfa el comando NLST para saber que ficheros concuer- 
dan con un patron, y despues una serie de comandos RETR para 
poderlos copiar. 

• mput: envfa una serie de comandos STOR. 
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mdelete: envfa el comando NLST y, a continuacion, una serie de 
comandos DELE. 




• quote: permite enviar un comando directamente al servidor (por 
ejemplo, quote syst). 

• ?: muestra un mensaje de ayuda. 

• quit o bye: envfa el comando QUIT y cierra el programa. 



18.1.5. Ejemplo de sesion FTP 

A continuacion, mostramos los mensajes intercambiados entre un 
cliente y un servidor en una hipotetica sesion de transferencia por 
medio de la utilidad ftp. 

Despues de cada comando de usuario, se muestran los mensajes en- 
viados, y se indica su origen y el destino (C para el cliente, S para el 
servidor), y el numero de puerto: 



open ftp.uoc.es 

C:4695 — » S:21 (establecimiento de conexion) 

S:21 — > C:4695 220 tibet FTP server (5.6) ready. <CRLF> 

(usuari) anonymous 

C : 4695 -> S:21 USER anonymous<CRLF> 

S:21 — > C:4695 331 Guest login ok, send ident 

as password . <CRLF> 

(contrasena) usuari@acme.com 

C : 4695 -> S:21 PASS usuari@acme . com<CRLF> 

S:21 — > C:4695 230 Guest login ok, access restrictions 

apply . <CRLF> 



cd pub 



C: 4695 -» S:21 
S : 2 1 C : 4 6 95 

dir 

C: 4695 -> S:21 
S : 21 -> C : 4 6 95 
C: 4695 -> S:21 



CWD pub<CRLF> 

250 CWD command successful . <CRLF> 

PORT 193, 146, 196, 254, 18, 88<CRLF> 
200 PORT command successful . <CRLF> 
LI ST<CRLF> 



S : 2 0 -> C : 4 6 9 6 
S : 21 -> C : 4 6 95 

S : 2 0 -> C : 4 6 9 6 



(establecimiento de conexion) 

150 ASCII data connection for /bin/ls 
(193.146.196.254,4696) (0 bytes ). <CRLF> 

total 2 0<CRLF> 

drwxr-xr-x 7 0 other 512 Aug 3 07:10 
. <CRLF> 



S:20 — > C:4696 (cierre de conexion) 

S : 21 -> C : 4 6 95 226 ASCII Transfer complete . <CRLF> 



229 



cd doc 

C : 4 6 95 -> S : 21 



S : 21 


— > 


C : 4 6 95 


dir 






C : 4 6 95 


-> S : 21 


S : 21 


— > 


C : 4 6 95 


C : 4 6 95 


-> S : 21 


S : 20 


— > 


C : 4 6 97 


S : 21 


— > 


C : 4 6 95 


S : 20 


— > 


C : 4 6 97 



S : 20 


— > 


C : 4 6 97 


S : 21 


— > 


C : 4 6 95 


get 


README 


C : 4 6 95 


-> S : 21 


S : 21 


— > 


C : 4 6 95 


C : 4 6 95 


-> S : 21 


S : 20 


— > 


C : 4 6 9 9 


S : 21 


— > 


C : 4 6 95 


S : 20 


— > 


C : 4 6 9 9 


S : 20 


— > 


C : 4 6 9 9 


S : 21 


— > 


C : 4 6 95 


bye 






C : 4 6 95 


-> S : 21 


S : 21 


— > 


C : 4 6 95 


S : 21 


— > 


C : 4 6 95 



CWD doc<CRLF> 

250 CWD command successful . <CRLF> 

PORT 193, 146, 196, 254, 18, 89<CRLF> 

200 PORT command successful . <CRLF> 

LI ST<CRLF> 

(establecimiento de conexion) 

150 ASCII data connection for /bin/ls 
(193.146.196.254,4697) (0 bytes ). <CRLF> 

total 8 8 6<CRLF> 

drwxr-xr-x 2 0 other 512 Oct 24 1996 .<CRLF> 



(cierre de conexion) 

226 ASCII Transfer complete . <CRLF> 

PORT 193, 146, 196,254, 18, 91<CRLF> 

200 PORT command successful . <CRLF> 
RETR README <CRLF> 

(establecimiento de conexion) 

150 ASCII data connection for README 
(193.146.196.254,4699) (95 bytes) .<CRLF> 

(contenido del fichero) 

(cierre de conexion) 

226 ASCII Transfer complete . <CRLF> 



QUIT<CRLF> 

221 Goodbye. <CRLF> 
(cierre de conexion) 



18 . 2 . EITFTP 



Hay situaciones en las que se necesita transferir ficheros de un orde- 
nador a otro y el FTP no es apropiado, principalmente a causa de su 
complejidad. 



Nota 

Un ejemplo tfpico en el que se observa la necesidad 
de transferir ficheros de un ordenador a otro es el de 
las estaciones de trabajo sin disco, que cargan el sis- 
tema operativo por medio de la red. En este caso, 
debe haber un ordenador que funcione como "servi- 
dor de arranque" de la estacion, proporcionandole el 
fichero o ficheros en que se encuentra el codigo execu- 
table del sistema operativo. 



230 



Un pequeno programa residente en la memoria ROM 
de la estacion debe controlar la transferencia de los fi- 
cheros. 

Para esta operacion el FTP no es adecuado, puesto 
que requiere una implementacion del protocolo de 
transporte TCP, establecer en el mismo diferentes co- 
nexiones simultaneas, etc. 



Para satisfacer las necesidades de transmisiones simpli- 
ficadas, se ha definido el TFTP, cuya ultima version esta 
especificada en el estandar RFC 1350. 

Este protocolo esta basado en datagramas, solo propor- 
ciona dos operaciones (leer y escribir ficheros) y no hay 
ningun tipo de identificacion ni autenticacion de usuario. 



18.2.1. Conceptos basicos del TFTP 

Como el TFTP se basa en datagramas, generalmente se utiliza con el 
protocolo de transporte UDP. El numero de puerto al que el cliente 
debe enviar las peticiones de servicio es el 69. 

Una transferencia TFTP se inicia con un datagrama enviado por el 
cliente en el que se solicita la operacion deseada: leer o escribir un 
fichero. A partir de entonces, se establece un dialogo en el que cada 
parte envfa un datagrama de manera alternada. Cada uno de estos 
datagramas sirve de confirmacion de recepcion del anterior. Elio signi- 
fica que en cada momento solo puede haber un datagrama pen- 
diente de ser confirmado. 



Lectura complementaria 



Si quereis mas informacion 
sobre el TFTP, consultad la 
obra siguiente: 

K. Sol I ins (1992, julio). RFC 
1350 - The TFTP protocol. 



De este modo, la recuperacion de los errores de transmision es muy 
simple: si pasa un tiempo sin que llegue la respuesta a un datagra- 
ma, se reenvla y si se recibe un datagrama que ya se habla recibido 
con anterioridad, se ignora. Por tanto, basta con guardar el ultimo 
datagrama enviado por si debe retransmitirse. 
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El cliente debe enviar su primer datagrama desde un puerto C al 
puerto 69 del servidor. Cuando lo recibe, el servidor elige un numero 
de puerto S que deberfa ir cambiando en cada transferencia. Todos 
los datagramas que envfe el servidor tendran como puerto de origen 
el numero S y como puerto de destino el numero C; todos los da- 
tagramas que envie el cliente, excepto el primero, tendran como 
puerto de origen el numero C y como puerto de destino el numero S. 
Elio permite detector una posible duplicacion del primer datagrama: 
si el servidor lo recibe dos veces o mas, debe enviar ambas respues- 
tas desde puertos diferentes; el cliente aceptara la primera y enviara 
mensajes de error a los puertos de los que provengan las otras. 



Nota 



Habra un ultimo bloque de 
cero bytes solo cuando la 
longitud del fichero que 
deba transmitirse sea multi- 
plo de 51 2. 



En el transcurso de la transferencia, una de las partes envta los datos del 
fichero y la otra solo envfa confirmaciones. Los datos se envian en blo- 
ques de longitud fi ja, 512 bytes, excepto el ultimo bloque, que tendra 
entre 0 y 51 1 bytes. Cada bloque se envta en un datagrama. 

La transferencia se acaba cuando el receptor recibe el ultimo bloque de 
datos y envta la confirmacion correspondiente. En este momento, puede 
dar por finalizada la comunicacion. Opcionalmente, puede esperar por 
si vuelve a recibir el ultimo bloque, lo que significarta que la ultima con- 
firmacion no ha llegado al emisor. Si sucede esto, solo es preciso reen- 
viar esta confirmacion. 



Por su parte, el emisor dara por acabada la transferencia cuando reciba 
la ultima confirmacion o cuando haya transcurrido cierto tiempo re- 
transmitiendo el ultimo bloque de datos y no reciba respuesta. En este 
ultimo caso, podrta ser que la transferencia se hubiera efectuado correc- 
tamente y que el unico problema estuviera en la transmision de la ultima 
confirmacion. 



18.2.2. Functonalidad del TFTP 

El TFTP ofrece dos operaciones basicas: leer ficheros del servidor y 
escribir ficheros en el servidor. El datagrama inicial indica la opera- 
cion que el cliente quiere llevar a cabo y tiene el formato siguiente: 



Figura 81 . 














1 
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El codigo de operacion es un numero de dos bytes, que puede ser 
RRQ o WRQ si el cliente solicita leer o escribir un fichero, respectiva- 
mente. A continuacion, existen dos cadenas de caracteres, acabadas 
con un byteigual a cero: la primera es el nombre del fichero y la se- 
gunda es el modo de transferencia (el equivalente del tipo de repre- 
sentacion en FTP). Esta segunda cadena puede ser netascii u 
octet (en caracteres ASCII, y en cualquier combinacion de mayus- 
culas y minusculas). El primer valor indica que los datos son carac- 
teres ASCII tal como se usan en el protocolo Telnet, y el segundo 
indica que los datos son bytes arbitrarios de 8 bits. 



Not a 

En versiones anteriores del protocolo, habia un tercer 
modo de transferencia llamadomail, solo aplicable a 
las operaciones de escritura, en el que el nombre del 
fichero era sustituido por el nombre de un usuario que 
debia recibir los datos por correo. 



Los datagramas que contienen los datos y las confirmaciones de re- 
cepcion tienen los formatos siguientes: 



Figura 82. 




El primer campo es el codigo de operacion y el segundo es el numero 
de bloque que se envia o se confirma (ambos campos son de dos bytes). 
Cada bloque del fichero tiene un numero correlativo, empezando 
por 1 , que sirve para distinguir las confirmaciones duplicadas. 

Si el cliente envia un datagrama inicial RRQ, el servidor contesta con 
un datagrama DATA con numero de bloque igual a 1 y, si el cliente 
envia un datagrama inicial WRQ, el servidor contesta con un datagra- 
ma ACK con numero de bloque igual a 0 y, a continuacion, el cliente 
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envfa el primer datagrama de datos. Entonces, cliente y servidor se 
intercambian datagramas ACK y DATA de manera alternada, con las 
retransmisiones necesarias si no llega el datagrama que correspon- 
de en cada momento. 

El TFTP tambien preve la terminacion de la transferencia si se produ- 
ce algun error. Cuando se detecta el error, se envfa un datagrama 
con el formato siguiente: 



Figura 83. 











Nota 



Si llega un datagrama del 
servidor con un numero de 
puerto de origen incorrecto 
(probablemente a causa de 
un datagrama inicial dupli- 
cado), la transferencia con 
este puerto queda interrum- 
pida, pero la que utiliza el 
puerto correcto debe conti- 
nuar con normalidad. 



Los dos primeros campos son el codigo de operacion y el codigo de 
error (cada uno de dos bytes). A continuacion, hay una cadena de ca- 
racteres, acabada en 0, que puede servir para describir a un usuario 
humano la causa del error. 

Un datagrama de error indica que se da por acabada la transferen- 
cia y no debe confirmarse ni, portanto, retransmitirse. Ahora bien, si 
por alguna razon se pierde este datagrama, la otra parte interpreta- 
ra que la transferencia ha acabado prematuramente cuando haya 
transcurrido cierto tiempo retransmitiendo sin recibir nada. 



En las tablas siguientes se presenta una relacion de los codigos nu- 
mericos asignados a cada operacion y a cada tipo de error TFTP: 



Tablas 10 y 11. 



Codigo 


Error 


0 


Error indefinido (vease el mensaje) 


1 


No se ha encontrado el fichero 


2 


Acceso denegado 


3 


Disco lleno 


4 


Operacion novalida 


5 


Numero de puerto incorrecto 


6 


Ya existe el fichero 


7 


Usuario incorrecto (en modomail) 



Codigo 


Operacion 


1 


RRQ 


2 


WRQ 


3 


DATA 


4 


ACK 


5 


ERROR 
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18.2.3. Implementaciones del TFTP 



En muchos sistemas Unix y distribuciones GNU/Linux hay un servidor 
del TFTP llamado tftpd. Como no existe ningun tipo de identifica- 
cion de usuario, los clientes pueden acceder en principio a cualquier 
fichero con permisos de acceso publico. En algunos sistemas, sin em- 
bargo, puede restringirse el acceso a un directorio o unos directories 
determinados. No obstante, el servicio TFTP suele estar inhabilitado, 
y solo lo ofrecen los sistemas en que se necesita por algun motivo 
concreto (por ejemplo, los servidores de arranque de las estaciones 
sin disco). 



Nota 



Por norma general hay un 
directorio llamado /tftp- 
boot en el que se guardan 
las imagenes de los siste- 
mas operativos de los clien- 
tes sin disco, y solo se 
permite a este directorio el 
acceso por medio del TFTP. 



Asimismo, hay un programa cliente llamado tftp que funciona de 
manera similar a la utilidad ftp: admite comandos como get, put, 
ascii, binary o quit (pero no cd, dir, delete, rename, etc., 
porque el protocolo no los soporta). 
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19. Correo electronico Internet 



El correo electronico es la aplicacion distri buida que 
permite enviar mensajes electronicos por medio de sis- 
temas informaticos. 



Al especificar esta aplicacion, se considero adecuado que todas sus 
caracterfsticas siguieran las ideas basicas del correo postal: 



• Las operaciones permiten basicamente enviar mensajes y recibirlos. 



• Los elementos son equivalentes a los mensajes, los usuarios, las 
oficinas de correo y los buzones. 



• La funcionalidad esta basada en la filosoffa del almacenamiento y 
el reenvfo: cuando un mensaje llega a una oficina de correos, esta 
ultima lo almacena y no lo reenvfa hasta el momento en que lo con- 
sidera oportuno. De este modo, los mensajes van de oficina de co- 
rreos en oficina de correos hasta que llegan al destinatario. 

Para llevar a cabo esta funcionalidad, se definieron los protocolos si- 
guientes: 



Nota 



La filosofia del almacena- 
miento y el reenvio permite 
superar problemas como 
las caidas de la red; en este 
caso, los mensajes no se 
pierden, puesto que en 
cada momento hay una ofi- 
cina responsable del men- 
saje. 



• SMTP ( simple mail transfer protocol), para la transferencia de 
mensajes. 



• POP3 ( post office protocol ), para el acceso simple a buzones de 
correo. 



• IMAP4revl ( Internet message access protocol ), para el acceso 
complejo a buzones de correo. 

Tambien fue necesario definir un formato de mensaje, el RFC 822, 
que con posterioridad se amplio y dio lugar al formato MIME. 
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1 9.1 . Formato de (os mensajes: el RFC 822 



Lectura complementaria 



Si deseais mas informacion 
sobre el formato de los 
mensajes de correo Internet, 
el RFC 822, consultad la 
obra siguiente: 

D. Crocker (1982, 13 de 
agosto). RFC 822 - Standard 
for the format of ARP A Internet 
text messages. 



Antes de describir los diferentes protocolos relacionados con el co- 
rreo electronico, es preciso ver cual es el formato o la norma de los 
mensajes que se utiliza en el mismo. Este formato recibe el nombre 
del estandar en que se especifica, RFC 822, y se basa en los elemen- 
ts ttpicos de las cartas postales; es decir, el sobre, que contiene la 
informacion del destinatario y del remitente de la carta, el contenido, 
que es el mensaje en st. 

El estandar especifica que los mensajes de correo electronico estan 
formados por las dos partes siguientes: 



Nota 



Consultad en el anexo 3 la 
notacion que se utiliza para 
describir los campos de los 
mensajes. 



La cabecera, que recoge la informacion general del mensaje. 
Equivale al sobre de la carta postal y esta formada por una serie 
de campos de cabecera, cada uno de los cuales incluye un tipo 
concreto de informacion. 

El cuerpo del mensaje, que contiene el mensaje en st. Corres- 
ponde al contenido de la carta postal. Esta parte es opcional. 



Cada campo de cabecera consta de un nombre del campo (que 
identifica el tipo de informacion) seguido por el caracter opcio- 
nalmente acompanado por un cuerpo del campo (que incluye la in- 
formacion del campo), y acaba con un caracter <CRLF>. El formato 
de los campos es el siguiente: 



NombredelCampo : [ CuerpodelCampo] <CRLF> 



Por norma general, cada campo de cabecera se representa en una 
sola Itnea, empezando desde el primer caracter de la misma. En el 
caso de que se necesite mas de una, es preciso codificar estas Itneas 
adicionales empezando por un caracter, o mas, de espacio o tabu- 
lador. 
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El cuerpo del mensaje es simplemente una secuencia de Itneas con 
caracteres ASCII. El cuerpo esta separado de la cabecera por una It- 
nea nula (es decir, por la secuencia <CRLFXCRLF>). 





Algunos sistemas de correo electronico permiten reenviar mensajes a 
los usuarios. Por este motivo, se incluyen en el mismo unos campos de 
cabecera con informacion sobre el reenvfo. Estos campos son los que 
llevan el prefijo Resent- y tienen la misma semantica que los cam- 
pos correspondientes que no lo llevan. No obstante, siempre conven- 
dra tener presente que, dentro de un mensaje, los campos que llevan 
prefijo son los mas recientes. 



19.1.1. Informacion de la cabecera 



Los campos de cabecera del mensaje deben proporcionar informa- 
cion general del mensaje, incluyendo la informacion equivalente a 
la de un sobre postal; de este modo, encontramos los campos si- 
guientes: 



Nota 



Consulted el formato de las 
direcciones para identificar 
los buzones de usuario en el 
apartado 1 9.2.2. 



1) Originador (From/Resent-From)) 



La identidad y la direccion del buzon de la persona o las perso- 
nas que originan el mensaje se puede incluir en el campo From 
o Resent-From. En este campo, se puede introducir la direccion 
del buzon de un originador o mas. 



From: lidireccion 
Resent-From: l#direccion 



2) Destinatario (To/Resent-To) 

El RFC 822 identifica al destinatario o destinatarios principales del 
mensaje por medio del campo To o Resent-To. En este campo, se 
puede introducir la direccion de un destinatario o mas. 



To: l#direccion 
Resent-To: l#direccion 



3) Destinatario de copia (Cc/Resent-cc) 

Asimismo, existe la posibilidad de enviar copias de un mensaje. En este 
caso, la identidad del receptor o receptores secundarios del mensaje 

239 




se especifica con el campoCc o Resent-cc. En este ultimo, se puede 
introducir la direccion de un destinatario de copia o mas. 



Cc: Udireccion 
Resent-cc: Udireccion 



4) Destinatario adicional (o de copia ciega) (Bcc/Resent-bcc) 

Cuando se desea enviar una copia del mensaje a destinatarios adi- 
cionales, sin que ninguno de ellos (los principales, los de copia y los 
de copia ciega) sepan que otros destinatarios la han recibido, se utiliza 
el campo Bcc o Resent-bcc que no lo ve ninguno de ellos. 



Bcc: Udireccion 
Resent-bcc: Udireccion 



5) Destinatario de respuesta (Reply-To/Resent-Reply-To) 

La identificacion del destinatario o destinatarios a los que deben 
enviarse las respuestas se puede llevar a cabo por medio del 
campo Reply-To o Resent-Reply-To ; en este ultimo se pue- 
de introducir la direccion de un destinatario de la respuesta o 
mas. 



Reply-To: lidireccion 
Resent-Reply-To : 1# direccion 



6) Asunto (Subject) 

Otra posibilidad que ofrece el RFC 822 es enviar un texto explicativo 
del asunto del mensaje con el campo Subject. 



Subject: texto 



7) Data (Date/Resent-Date) 

Dentro de un mensaje tambien puede incluirse la hora y la fecha en 
que se envia por medio del campo Date o Resent-Date. El primer 
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sistema de correo que recibe el mensaje genera automaticamente 
este campo. 



Date: fecha-hora 
Resent-Date: fecha-hora 



8) Sistema remitente (Sender/Resent-Sender) 

Algunas veces el usuario que envfa el mensaje no es el mismo que el 
autor. En estos casos, la identidad del agente (persona, sistema o 
proceso) que envfa en realidad el mensaje se identifica con el campo 

Sender o Resent-Sender. 



Sender: buzon 
Resent-Sender: buzon 



9) Camino de retorno hacia el originador (Return-path) 

El mensaje puede incluir la identificacion del camino de retorno ha- 
cia el originador del mensaje con el campo Return-path. Este 
campo lo anade el sistema de transporte final que entrega el men- 
saje al receptor. 



Return-path: addr-ruta 



10) Informacion de sistemas intermedios (Received) 

Existe la posibilidad de que cada sistema de transporte intermedio 
por el cual pasa el mensaje incluya informacion de los sistemas emi- 
sor (from) y receptor (by), del mecanismo ffsico (via), del identifica- 
dor del mensaje (id), de las especificaciones originales (for) y de la 
hora de recepcion por medio del campo Received. Cada sistema 
intermedio anade una copia de este campo al mensaje. 



Received: 

[from dominio ] 
[by dominio] 
[via atom ] 

* ( with atom) 

[id id-ms g ] 

[for addr-spec] 
; fecha-hora 
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1 1 ) Identificador del mensaje (Message-ID/Resent-Message-ID) 



Cada mensaje debe incluir un identificador unico del mensaje, para que 
pueda ser contestado o referenciado con posterioridad, en el campo 
Message-ID o Resent-Message-ID. El sistema que genera el iden- 
tificador es el encargado de asegurar que el identificador sea unico. 



Message-ID: id-msg 
Resent-Message-ID: id-msg 



12) Identificador del mensaje contestado (In-Reply-To) 

Cuando un mensaje constituye la respuesta de un mensaje anterior, 
el mensaje original se puede referenciar por medio de su identifica- 
dor dentro del campo In-Reply-To. 



In-Reply-To : 

*(frase I id-msg) 



13) Identificador de mensajes referenciados (References) 

Si se desea enviar un mensaje que se refiere a otros mensajes, el 
identificador del mensaje referenciado se puede incluir dentro del 
campo References. 



References : 

*(frase \ id-msg) 



14) Palabras clave (Keywords) 

Las palabras clave o frases referentes al mensaje se pueden incluir, 
separadas por comas, dentro del campo Keywords. 



Keywords : if rase 



15) Comentarios (Comments) 

Se puede incluir un texto de comentario en el mensaje, sin interferir 
su contenido, por medio del campo Comments. 



Comments : texto 
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16) Identification del mecanismo de cifrado (Encrypted) 

El RFC 822 permite cifrar el cuerpo del mensaje. En este caso, es con- 
veniente enviar una o dos palabras que identifiquen el mecanismo 
de cifrado que se ha aplicado utilizando el campo Encrypted 



Encrypted: l#2palabras 



Nota 

El RFC 822 solo define la sintaxis para especificar un 
mecanismo de cifrado; sin embargo, no especifica el 
mecanismo ni la manera de utilizarlo. 



17) Campos de uso personal. 

El estandar permite tambien que los usuarios definan campos para 
uso personal. El nombre de los campos creados por un usuario debe 
empezar obligatoriamente por la cadena X- . 



X- campo -uso -personal 



18) Campos de extension 

En el futuro se pueden estandarizar nuevos campos de cabecera. 
Para que no haya conflictos con los campos de uso personal, el nom- 
bre de los campos nunca empezara por la cadena X-. 



campo -ex tens ion 




El estandar RFC 822 establece que los unicos cam- 
pos de cabecera que son obligatorios en un mensaje 
son los siguientes: fecha (Date), originadores 
(From), y destinatario (To) o destinatario de copia 
ciega (Bcc). 
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19.1.2. Ejemplo 



En este apartado se presenta un ejemplo de mensaje RFC 822 en el 
que se pueden apreciar los compos de cabecera mas tfpicos, asf 
como un cuerpo breve del mensaje. Conviene recordar que es un 
mensaje en ASCII de 7 bits. 

Date: 25 Jun 2003 0932 PDT 

From: Jordi Inyigo < j inyigo@uoc . edu> 

Subject: Ejemplo mensaje RFC 822 
Sender: jmmarques@uoc.edu 
Reply-To: jinyigo@uoc.edu 
To: Ramon Marti <rmarti@uoc.edu>, 
xpe rramon@uoc . edu 

Cc : Llorenc Cerda <lcerda@uoc.edu>, 

Jose Barcelo < jbarcelo@uoc . edu>, 
epeig@uoc . edu 

Comment: os envio esta informacion que os puede interesar 
In- Reply-To: <1234321 . 5678987650 uoc. edu> 

Received: from uoc.edu by peru.uoc.es 

(8 . 8 . 5/8 . 8 . 5) with ESMTP id SAA14826 
for <rmarti@uoc . edu >; Fr i , 20 Jun 2003 
18:35:52 +0200 (MET DST ) 

Received: from rectorat . uoc . edu ( 14 7 . 8 3 . 35 . 35 ) 
by uoc.es via smap (V2.0) id xma020193; 

Mon, 20 Jun 2003 18:38:50 +0200 for 
rmarti@uoc . edu 

Mess age -Id: <199809211639. SAA20364@uoc . edu> 

Este mensaje tiene formato RFC 822 e incluye 
algunos de los campos de cabecera mas utilizados. 



Actividad 

Coged un mensaje de correo electronico que hayais re- 
cibido y analizad toda la cabecera. Identificad todos los 
campos y tratad de averiguar quien es el responsable 
de crear cada uno de los campos. 



19.2. El SMTP 



Lectura complementaria 



Si quereis mas informacion 
sobre el SMTP, consultad la 
obra siguiente: 

J. Postel (1982, 1 de agos- 
to). RFC 821 - Simple Mail 
Transfer Protocol. 



El SMTP es el protocolo mas utilizado en Internet para transferir men- 
sajes de correo electronico. Proporciona la funcionalidad necesaria 
para conseguir una transferencia fiable y eficiente de mensajes de co- 
rreo entre ordenadores que actuan como oficina de correos. Siguien- 
do las ideas del correo postal, el SMTP se basa en el almacenamiento 
y el reenvio. Es decir, cuando un mensaje llega a una oficina, queda 
almacenado en la misma cierto tiempo antes de ser entregado a otra 
oficina o al destinatario final. Conviene senalar, asimismo, que cada 
usuario debe disponer de un buzon para recibir mensajes, el cual 
siempre debe estar asociado a una oficina determinada. 
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19.2.1. Modelo del SMTP 



Desde el punto de vista del modelo, el SMTP debe proporcionar los 
elementos necesarios para la transferencia de mensajes. Por ello, se 
definen los elementos siguientes: 



• Agente de usuario: se encarga de introducir los mensajes en el 
sistema de correo SMTP. 

• Emisor SMTP: se ocupa de realizar las conexiones y de enviar 
mensajes a receptores SMTP a partir de peticiones de los usuarios. 
Generalmente, cada emisor SMTP tiene asociada una cola de 
mensajes, en la que se almacenan los mensajes antes de ser re- 
enviados (siguiendo la filosoffa del almacenamiento y el reenvfo). 

• Receptor SMTP: se encarga de recibir los mensajes. Si el mensaje 
va destinado a un usuario asociado al mismo sistema en que se 
encuentra el receptor SMTP, este deposita el mensaje en el buzon 
del destinatario. En caso contrario, el receptor SMTP deposita el 
mensaje en la cola de mensajes del emisor SMTP asociado, que 
lo recupera y lo reenvfa hacia el receptor SMTP de otra oficina 
mas proximo al destinatario. 



Nota 



El agente de usuario, defini- 
do en la mayorfa de los es- 
tandares, es equivalente al 
elemento usuario especifi- 
cado en el modelo cliente/ 
servidor. Puede ser tanto 
otra aplicacion, como una 
persona por medio de una 
interfaz de usuario. 



Conviene destacar que los sistemas que actuan como oficina deben 
disponer al mismo tiempo de un receptor SMTP (para recibir los men- 
sajes), de buzones de los usuarios y de un emisor SMTP (para poder 
reenviar los mensajes) con una cola de mensajes. 



La figura siguiente nos muestra el modelo de un sistema SMTP: 
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Nota 



Nota 



El nombre de dominio suele 
estar formado por la se- 
cuencia de nombres de los 
subdominios de los que de- 
pende jerarquicamente se- 
parados por el caracter 



Nota 



Cada ordenador que actua 
como oficina de correos 
suele definir un dominio de 
correo, que se identifica con 
un nombre de dominio. Este 
nombre es el que se ercuen- 
tra en la parte dominio de 
la direccion electronica de 
los usuarios que tienen los 
buzones en estas mdquinas. 



Notad que este modelo, asf como los otros que se es- 
tudiaran en este modulo, sigue el modelo cliente/ser- 
vidor definido con anterioridad. Asimismo, conviene 
remarcar que cada estandar proporciona un nombre 
diferente a los elementos del modelo cliente/servidor. 
En el estandard que nos ocupa, el usuario equivale al 
agente de usuario, el cliente equivale al emisor SMTP 
y el servidor equivale al receptor SMTP. 



19.2.2. Direcciones de correo 

Para que el sistema de correo sea capaz de entregar un mensaje, se 
precisa algun mecanismo que permita definir direcciones para los 
buzones de los usuarios. En los protocolos Internet, la direccion de 
buzon esta formada por una cadena que identifica a un usuario 
(persona, sistema o proceso) y una cadena que identifica el sistema 
(dominio) en que se encuentra el buzon. 



direccion = usuario@dominio 
dominio = subdominio* ( . subdominio) 



Con este tipo de direccionamiento electronico, se tiene la funcionali- 
dad siguiente: 



• El mensaje se envta al sistema identificado por el nombre de do- 
minio que se encuentra en la direccion a la derecha del signo @ 
(es decir, dominio). 

• Una vez en el sistema, el mensaje se entrega al buzon del usuario 
identificado en la direccion a la izquierda del signo @ (es decir, 

usuario). 

• El SMTP proporciona tambien la posibilidad de definir listas de 
correo, que constituyen listas de destinatarios identificadas por 
una unica direccion. Esta ultima es la que se utiliza para enviar 
mensajes a la lista, y el sistema SMTP se encarga de expandirla y 
enviar el mensaje a todos los usuarios que sean miembros de la 
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misma en aquel momento. Este metodo permite la modificacion 
de la lista sin necesidad de cambiar la direccion. 



19.2.3. Envfo de correo y mensajes a terminales 

Ademas del envfo de mensajes de correo a buzones (en el estandar, 
mail), que es su proposito principal, el SMTP tambien soporta la en- 
trega de mensajes al terminal del destinatario (en el estandar, send). 
Como la implementacion de estos dos metodos es muy similar, el 
SMTP define comandos en que combina. 



19.2.4. Conceptos basicos del SMTP 

El SMTP esta basado en conexiones TCP y el puerto que tiene asig- 
nado es el 25. 

Como hemos comentado al describir el modelo, el emisor SMTP 
hace llegar mensajes de correo al receptor. Para conseguirlo, se es- 
tablece un dialogo entre los dos con comandos que envfa al emisor 
y respuestas con las que contesta el receptor. 

Tanto los comandos como las respuestas SMTP siguen las reglas es- 
pecfficas del protocolo Telnet. Es decir, constituyen cadenas de ca- 
racteres codificados con bytes segun el codigo ASCII y se utiliza la 
secuencia <CRLF> para representor el final de Ifnea. 

• Los comandos SMTP estan formados por un codigo constituido 
por cuatro caracteres alfanumericos y, segun los comandos, un 
espacio y una serie de parametros. 

• Las respuestas SMTP estan formadas por un codigo numerico de tres 
dfgitos que, habitualmente, va seguido de un texto descriptivo. 

En los apartados siguientes se describiran los comandos definidos y 
las posibles respuestas. 



19.2.5. Funcionalidad del SMTP 

Es preciso diferenciar entre funcionalidad basica y funcionalidad adi- 
cional. 
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Software libre 



Funcionalidad basica 

Una vez conectado, el emisor SMTP se identifica ante el receptor 
SMTP con el comando HELO. 



HELO dominio 



Cuando se quiere iniciar el envfo de un mensaje de correo, se utiliza 
el comando MAIL, que incluye la identificacion del sistema desde el 
que se envfa el mensaje. Este comando da lugar al campo FROM: 
del mensaje. 



MAIL FROM: originador 



Con el comando RCPT se identifican los receptores del mensaje. Se 
debe utilizar uno para cada receptor, y cada llamada da lugar a un 
campo de cabecera TO : en el mensaje. 



RCPT TO: receptor 



El comando DATA indica el inicio del envfo del cuerpo del mensaje. 
Las Ifneas siguientes a este comando se tratan como contenido del 
mensaje. Este ultimo se acaba con una Ifnea que solo incluye un pun- 
to; es decir, con la secuencia <CRLF> . <CRLF>. 



DATA 



Los datos que se envfan dentro de este campo son mensajes RFC 822, 
por lo que pueden incluir compos de cabecera en el inicio. Cuando el lo 
sucede, entre los compos de cabecera y el cuerpo del mensaje debe ha- 
ber una Ifnea en bianco, es decir, la secuencia <CRLF><CRLF>. 



Una vez iniciada la transaccion de envfo de mensaje, y antes de aca- 
bar, el emisor SMTP siempre puede interrumpirla por medio del co- 
mando RSET . 



RSET 
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El comando NOOP sirve para que el receptor SMTP envfe una respuesta 
afirmativa para informar de que la conexion todavfa esta abierta. 



NOOP 



Para cerrar el canal de transmision, el SMTP proporciona el coman- 
do QUIT. Cuando este ultimo llega al receptor SMTP, este envta una 
respuesta afirmativa y cierra el canal de transmision. 



QUIT 



Funcionalidad adicional 

El protocolo STMP posibilita tambien una funcionalidad adicional 
con el objetivo de enviar mensajes a terminales. 

Para iniciar la entrega de un mensaje, o varios, a terminales, el emi- 
sor SMTP dispone del comando SEND. 



SEND FROM: originador 



El comando SOML permite iniciar la entrega de un mensaje, o varios, 
a terminales si el usuario se encuentra en el terminal, o, en caso con- 
trario, permite entregar el correo al buzon o a los buzones. 



SOML FROM: originador 



El comando SAML permite iniciar la entrega de un mensaje, o varios, 
a terminales y, al mismo tiempo, al buzon o a los buzones. 



SAML FROM: originador 



El emisor SMTP tambien puede pedir la confirmacion de que una ca- 
dena identifica a un usuario por medio del comando VRFY. 



VRFY cadena 
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El comando EXPN permite solicitor confirmacion para una cadena 
que identifica una lista de correo y, en caso de respuesta positiva, re- 
querir la relacion de los miembros de la lista. 



EXPN cadena 



El comando HELP permite pedir ayuda al receptor SMTP sobre los 
comandos que soporta. En caso de incluir una cadena como argu- 
mento, esta ultima puede identificar un comando, del que se retorna 
informacion especifica. 



HELP [ cadena ] 



El comando TURN permite cambiar el pa pel de emisor SMTP y recep- 
tor SMTP. El resultado de la peticion puede ser que el receptor SMTP 
envfe una respuesta afirmativa y haga el papel de emisor SMTP, o 
que envie una respuesta negativa y mantenga su papel. 



TURN 



19.2.6. Codigos de respuesta 

El SMTP define una serie de codigos de respuesta para los diferentes 
comandos, tanto en caso de exito (e), como en caso de resultado in- 
termedio (i), de fallo (F) y de error (x). La tabla siguiente recoge es- 
tos codigos: 



Tabla 12. 



Codigos de respuesta 




Establecimiento 
de connexion 


HELO 


MAIL 


RCPT 


DATA 


RSET 


SEND 


SOML 


SAML 


VRFY 


EXPN 


HELP 


NOOP 


QUIT 


TURN 


21 1 Estatus del sistema o respuesta 
a peticion de ayuda 
























E 








2 1 4 Mensaje de ayuda 
























E 








220 El servidor esta preparado 


E 
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Codigos de respuesta 





Establecimiento 
de connexion 


HELO 


MAIL 


RCPT 


DATA 


RSET 


SEND 


SGML 


S AML 


VRFY 


EXPN 


HELP 


NOOP 


QUIT 


TURN 


221 El servidor esta cerrando 
el canal de transmision 




























E 




250 Accion completada 
correctamente 




E 


E 


E 


E 


E 


E 


E 


E 


E 


E 


E 


E 




E 


251 Usuario no local, el mensaje 
se reenviara 








E 












E 












354 Principio de entrada de 
mensaje; es preciso acabar 
con <CRLF>.<CRLF> 










I 






















421 Servicio no disponible; cierre 
del canal de transmision 


F 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 




X 






450 Accion no ejecutada: buzon 
no accesible 








F 
























451 Accion abortada por error local 






F 


F 


F 




F 


F 


F 














452 Accion abortada por 
capacidad de almacenamiento 
insuficiente 






F 


F 


F 




F 


F 


F 














500 Error de sintaxis; comando 
no reconocido 




X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


501 Error de sintaxis 

en los parametros o argumentos 




X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 








502 Comando no implementado 














X 


X 


X 


X 


X 


X 






F 


503 Secuencia de comandos 
erronea 








X 


X 




















X 


504 Parametro de comando no 
implementado 




X 








X 








X 


X 


X 








550 Accion no ejecutada: buzon 
no encontrado 








F 












F 


F 










551 Usuario no local; intentar otra 
direccion 








F 












F 












552 Accion abortada por exceso 
de capacidad almacenada 






F 


F 


F 




F 


F 


F 














553 Accion no ejecutada; nombre 
de buzon no permitido 








F 












F 












554 Fallo en la transaccion 










F 
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El estandar establece el conjunto de comandos mfnimo 
que deben soportar todos los receptores SMTP: 



HELO dominio 

MAIL FROM: originador 

RCPT TO: receptor 

DATA 

RSET 

NOOP 

QUIT 



19.2.7. Extensiones SMTP para mensajes de 8 bits 

Se considero oportuno anadir un mecanismo para extender el SMTP. 
Cuando un cliente SMTP desea utilizar las extensiones SMTP, ast como 
las extensiones para mensajes de 8 bits, tiene que solicitarlo al receptor 
SMTP con el comando EHLO en lugar del comando HELO: 

EHLO dominio 



Lectura complementaria 



Para saber mas sobre las ex- 
tensiones SMTP para mensa- 
jes de 8 bits, consultad las 
obras siguientes: 

J. Klensin; N. Freed; M. Rose; 
E. Stefferud; D. Crocker 
(1995, noviembre). RFC 1869 
- SMTP Service Extensions. 

J. Klensin; N. Freed; M. Rose; 
E. Stefferud; D. Crocker 

(1994, julio). RFC 1 652 -SMTP 
Service Extension for 8bit- 
MIME transport. 



Si el receptor SMTP soporta las extensiones, retorna una respuesta o 
mas de exito (250) e indica las extensiones de fallo (550) o de error 
(501 ) que soporta. Si el receptor no las soporta, retorna una respues- 
ta de error (500, 502, 504 6 421). 



Una de las funcionalidades adicionales es la posibilidad de enviar 
mensajes de 8 bits. Cuando el servidor acepta mensajes de 8 bits, 
la respuesta de exito (250) incluye la cadena 8BITMIME. Cuando 
se quiera enviar el mensaje, debe indicarse que es de 8 bits. Elio 
se aplica a los comandos MAIL, SEND, SAML o SOML de la mane- 
ra siguiente: 



MAIL FROM: originador BODY = valor-cuerpo 
SEND FROM: originador BODY = valor-cuerpo 
SAML FROM: originador BODY = valor-cuerpo 
SOML FROM: originador BODY = valor-cuerpo 
valor-cuerpo = 7BIT | 8BITMIME 
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1 9.2.8. Ejemplo 



En este apartado se presenta un ejemplo en el que se puede observar 
la secuencia de comandos que envfa un emisor SMTP (en negrita) y las 
respuestas del receptor SMTP en una transaccion de envio de correo: 

220 peru.uoc.es SMTP/smap Ready. 

HELO campus.uoc.es 

250 (campus.uoc.es) pleased to meet you. 

HELP 

214-Commands 

214-HELO MAIL RCPT DATA RSET 

214 NOOP QUIT HELP VRFY EXPN 

NOOP 

220 OK 

EXPN xc@campus.uoc.es 

250-Jordi Inyigo < j inyigo@uoc . edu> 

250-Jose Barcelo<jbarcelo@uoc. edu> 

250-Llorenc Cerda <lcerda@uoc . edu> 

250-Ramon Marti <rmarti@uoc . edu> 

250-Enric Peig <epeig@uoc . edu> 

250 Xavier Perramon <xperramon@uoc . edu> 

MAIL FROM: jinyigo@uoc.edu 

250 jinyigo@uoc.edu... Sender OK 

RCPT TO: rmarti@uoc.edu 

250 rmarti@uoc.edu OK 

RCPT TO: rmarti@uoc.edu 

501 Syntax error 

RCPT TO: xperramon@uoc.edu 

250 xperramon@uoc.edu OK 

DATA 

354 Enter mail, end with on a line by itself 

Subject: Master de software libre 
Date: 20 Jun 2003 

Esto es un mensaje de correo de ejemplo. 

250 Mail accepted 

QUIT 

250 Closing connection 
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Not a 

Telnet como cliente generico de los protocolos 

El programa telnet esta pensado para hacer de 
cliente de servidores del protocolo Telnet. Sin embar- 
go, si se considera que lo que hace es enviar al servi- 
dor cadenas de caracteres tal como se introducen por 
el teclado y devolver por pantalla lo que recibe del ser- 
vidor, tambien se puede utilizar como cliente SMTP 
puesto que, como hemos comentado al describirlo, los 
mensajes que se intercambian en este protocolo son 
cadenas de caracteres ASCII. Este mismo razonamien- 
to se puede aplicar al resto de protocolos que vere- 
mos: POP3, IMAP, NNTP y HTTP. 

De este modo, si se utiliza el programa telnet como 
cliente SMTP, se pueden enviar comandos SMTP al 
servidor escribiendolos por el teclado y viendo sus res- 
puestas por pantalla. Para ello, el programa telnet ad- 
mite como segundo parametro el numero de puerto 
donde debe conectarse. 

Por ejemplo, el dialogo anterior se podria haber rea- 
lizado haciendo: 

telnet peru.uoc.es 25 



1 9.3. Acceso simple a los buzones de correo: el POP3 

En sistemas pequenos no es practico, ni usual, soportar el SMTP, 
puesto que implica tener el sistema conectado y dispuesto a recibir 
mensajes en cualquier momento. Por este motivo, se vio la necesidad 
de definir un protocolo que permitiera la recuperacion de mensajes 
de buzones de correo remotos y se definio el POP3. 



Nota 

El POP y el POP2, dos protocolos definidos en las RFC 
918 y RFC 937 respectivamente, parten de la misma 
filosofia que el POP3; sin embargo, disponlan de un 
conjunto de comandos mas reducido. 
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No obstante, en este protocolo es preciso disponer de sistemas en los 
que se encuentren los buzones -un servidor POP3-, y deben estar co- 
nectados en todo momento, tanto para recibir los mensajes, como 
para recibir las peticiones de acceso a los buzones. Por lo que res- 
pecta a los clientes POP3, solo es necesario que se conecten cuando 
quieran acceder a su correo. 



El POP3 no especifica ningun metodo para el envfo de correo; otros 
protocolos de transferencia de correo, como el SMTP, proporcionan 
esta funcionalidad. 



19.3.1. Modelo del POP3 



Lectura complementaria 



Si quereis mas informacion 
sobre el SMTP, consultad la 
obra siguiente: 

J. Myers; M. Rose (1996, 
mayo). RFC 1939 - Post 
Office Protocol - Version 3 



El modelo funcional del POP3 se basa en los elementos siguientes: 



• Agente de usuario: utiliza el cliente POP3 para acceder a su 
correo. 

• Cliente POP3 : se comunica con el servidor POP3 por medio del 
protocolo POP3 para acceder a su buzon de correo. 

• Servidor POP3 : recibe peticiones de los clientes POP3 y se las sir- 
ve accediendo a los buzones correspondientes. 

En la figura siguiente se presentan los elementos del modelo funcio- 
nal del POP3 integrados en un sistema en el que se utiliza el SMTP 
para enviar el correo, y el POP3 para acceder a los buzones: 
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19.3.2. Conceptos basicos del POP3 



El POP3 se basa en comunicaciones TCP sobre el puerto 1 10. 

El mecanismo normal de utilization de dicho protocolo es el siguiente: 
cuando el cliente POP3 necesita acceder al buzon, se conecta con el ser- 
vidor POP3, recupera la informacion que le interesa y cierra la conexion. 

Cada vez que sea necesario volver a acceder al buzon, se establece 
una nueva conexion. 



• Los comandos POP3 constituyen cadenas de caracteres ASCII im- 
primibles acabados con <CRLF>. Todos los comandos incluyen 
un codigo alfanumerico de cuatro caracteres que identifica el co- 
mando, seguido de cero o mas parametros. 

• Las respuestas POP3 tambien son cadenas de caracteres ASCII, 
y se representan con un indicador de estado positivo (+0K) o ne- 
gativo (-ERR) y, posiblemente, informacion adicional, de la ma- 
nera siguiente: 

+0K el comando se ha ejecutado con exito 
-ERR el comando no se ha ejecutado con exito 



Estados 

La norma define tres estados por los que debe pasar toda sesion 
POP3: 

• Una vez se ha abierto la conexion, la sesion entra en elestado de 
autorizacion, en que el cliente debe identificarse ante el servidor 
POP3. 

• Una vez autorizado, la sesion pasa al estado de transaccion. En 
este ultimo, el cliente pide acciones al servidor POP3 con los co- 
mandos necesarios. 

• Cuando el cliente llama el comando QUIT, la sesion entra en el 
estado de actualization. El servidor libera los recursos, se despi- 
de y cierra la conexion TCP. 
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19.3.3. Funcionalidad del POP3 



Desde el punto de vista de funcionalidad, y retomando los plantea- 
mientos del correo postal, el POP3 proporciona los comandos nece- 
sarios para el acceso a buzones de correo. A continuacion, 
describiremos los comandos correspondientes a cada uno de los es- 
tados por los que debe pasar una sesion POP3: 

1 ) Estado de autorizacion. En este estado el cliente se identifica ante 
el servidor POP3. Para realizar el proceso de identificacion, se dis- 
pone de los comandos siguientes: 

a) Identificacion de usuario (USER) 

Lo primero que debe hacer un cliente POP3 es identificarse ante 
el servidor POP3. Uno de los metodos es hacerlo mediante el co- 
mando USER, dentro del cual se envfa el nombre que identifica al 
usuario. 



USER nombre 



b) Envfo de la contraseiia (PASS) 

Una vez identificado el usuario mediante el comando USER, debe 
llevarse a cabo la autenticacion por medio del envfo de una contra- 
sena con el comando PASS. El servidor utiliza la cadena enviada en 
este ultimo junto con el nombre de usuario para dar acceso al usua- 
rio al buzon o denegarselo. 



PASS contraseiia 



c) Identificacion y autenticacion del usuario con seguridad (APOP) 

El metodo de identificacion y autenticacion mediante los comandos 
USER y PASS tiene el problema de que tanto el nombre como la con- 
trasena viajan por la red sin ningun mecanismo de seguridad. Un 
metodo alternative de identificacion y autenticacion del usuario con- 
siste en utilizar el comando APOP, que incorpora mecanismos de se- 
guridad en el envfo de la contraseiia. 



APOP nombre resumen 
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Not a 



El comando APOPactua de la manera siguiente: 

Al conectarse, el servidor envfa una cadena al cliente. 
Este ultimo concatena la cadena recibida a la contrase- 
na y crea un resumen de la misma por medio de un al- 
goritmo de creacion de resumenes ( hash criptografico). 
Este resumen se envfa junto con el nombre identificativo 
del usuario como argumentos del comando APOP. 

El servidor, para verificar el ususario, genera el mismo 
resumen y lo compara con el que ha recibido. 



2) Estado de transaccion. En este estado, el cliente solicita acciones 
al servidor POP3. Las acciones que puede pedir son las siguientes: 

a) Estado (STAT) 

Una vez autenticado el usuario, el cliente POP3 puede requerir infor- 
macion sobre el estado del buzon del usuario por medio del coman- 
do STAT que no tiene argumentos y devuelve el numero de mensajes 
y los bytes que ocupa el buzon del usuario. 



STAT 



b) Listado (LIST) 

Cuando ya se sabe el numero de mensajes que hay en el buzon, el 
paso siguiente es la peticion de informacion sobre uno de los men- 
sajes o sobre todos. El POP3 proporciona el comando LIST para 
esta tarea. Este comando devuelve, para cada mensaje, un numero 
de mensaje y los bytes que ocupa. 



LIST [ mensaje ] 



c) Recuperacion de mensajes (RETR) 

Una vez se conocen los mensajes que hay en el buzon, deben recu- 
perarse los que quiere leer. Elio puede hacerlo el cliente POP3, para 
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cada mensaje, con el comando RETR, que incluye como argumento 
el identificador del mensaje que se quiere recuperar. 



RETR mensaje 



d) Borrado de mensajes (DELE) 

Tras leer un mensaje, puede interesar borrarlo. El comando DELE in- 
dica al servidor POP3 que marque como mensaje a borrar el identi- 
ficado como tal en el argumento; sin embargo, el mensaje no se 
borrara hasta que no se entre en el estado de actualizacion. 



DELE mensaje 



e) Operacion nula (NOOP) 

El comando NOOP sirve para saber si la conexion con el servidor to- 
davfa esta abierta. Con dicho comando, el servidor POP3 no hace 
nada, excepto devolver una respuesta afirmativa. 



NOOP 



f) Desmarcado de mensajes para borrar (RSET) 

Una vez se ha llevado a cabo una llamada al comando DELE, y an- 
tes de entrar en el estado de actualizacion, el usuario puede echarse 
atras y pedir al servidor POP3, mediante el comando RSET, que des- 
marque todos los mensajes marcados para borrar. 



RSET 



g) Recuperacion de la parte superior de un mensaje (TOP) 

En ocasiones, puede interesar recuperar solo la parte superior de un 
mensaje para decidir si vale la pena recuperarlo todo o no. El co- 
mando TOP permite recuperar la cabecera y n lineas del mensaje 
identificado en el argumento. 



TOP mensaje n 



259 



h) Lista de identificadores unicos(UIDL) 



Todos los mensajes del buzon tienen un identificador unico ( unique- 
id ) permanente (a diferencia del numero de mensaje, que es unico 
dentro del buzon, pero que puede ir variando). El comando UIDL 
permite obtener el numero de mensaje y el identificador unico de uno 
de los mensajes del buzon o de todos. 



UIDL [ mensaje ] 



i) Paso al estado de actualizacion (QUIT) 

Una vez finalizadas las transacciones, el cliente POP3 debe llamar el 
comando QUIT para pasar al estado de actualizacion. 



QUIT 



3) Estado de actualizacion. En este estado, el servidor POP3, en 
primer lugar, borra todos los mensajes marcados para borrar y, 
con posterioridad, libera todos los recursos y cierra la conexion 
TCP. El estado de actualizacion no dispone de ningun comando 
asociado. 





El estandar establece que los servidores POP3 deben 
soportar como mmimo los comandos siguientes: 



USER nombre 
PASS cadena 
STAT 

LIST [ mensaje ] 

RETR mensaje 

DELE mensaje 

NOOP 

RSET 

QUIT 
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1 9.3.4. Ejemplo 



A continuacion, se presenta un ejemplo de los comandos de acceso 
de un cliente POP3 (en negrita) a un servidor POP3 para recuperar 
el mensaje enviado en el ejemplo anterior: 

+0K QPOP (version 2.52) at pop.uoc.es starting. 

USER rmarti 

+0K Password required for rmarti . 

PASS prueba 

-ERR Password supplied for "rmarti" is incorrect. 

+0K Pop server at pop.uoc.es signing off. 

PASS password 

+0K rmarti has 6 message(s) (190885 bytes). 

STAT 

+0K 6 190885 

LIST 

+0K 6 messages (190885 bytes) 

1 3140 

2 3326 

3 1911 

4 180846 

5 861 

6 801 

RETR 6 

+0K 801 

Received: from campus.uoc.es by peru.uoc.es 
(8. 8. 5/8. 8. 5) with ESMTP id SAA14826 
for <rmarti0uoc . edu>; Fri, 27 Jun 2003 
18:35:52 +0200 (MET DST) 

From: Jordi Inyigo < j inyigo0uoc . edu> 

Message-Id: 

<199809211639. SAA2O3640peru . uoc . es> 

To: rmarti0uoc.edu, xperramon0uoc.edu 
Subject: Master de software libre 
Date: 27 Jun 2003 
Content-Type: text 
Status: RO 

Este es un mensaje de correo de ejemplo. 

QUIT 

+0K Pop server at dns signing off 
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1 9.4. Acceso complejo a los buzones de correo: 
el IMAP4revl 

El protocolo de acceso a mensajes Internet, version 4revl , 
IMAP4revl , permite al cliente acceder a los mensajes de correo 
electronico de un servidor y manipularlos. 



El IMAP4revl (a partir de ahora lo llamaremos IMAP4 ) permite al 
usuario disponer de diferentes buzones estructurados de manera je- 
rarquica y, al mismo tiempo, poderlos manipular de manera remota, 
tal como se hace con los buzones locales. 



Nota 



El IMAP4revl surgio de la 
evolucion de las especifica- 
ciones IMAP2 [RFC 1176], 
IMAP3 [RFC 1 203] e IMAP4 
[RFC 1730]. 



El IMAP4 tambien proporciona a los clientes la capacidad de resin- 
cronizacion con el servidor. 

El IMAP4 no especifica ningun metodo para el envlo de correo; otros 
protocolos de transferencia de correo, como el SMTP, proporcionan 
esta funcionalidad. 



19.4.1. Modelo del IMAP4 



El modelo funcional del IMAP4 se basa en los elementos que presen- 
tamos a continuacion: 



• Agente de usuario: utiliza el cliente IMAP4 para leer el correo de 
su buzon. 



• Cliente IMAP4: se comunica con el servidor IMAP4 por medio del 
IMAP4 para acceder a su buzon de correo. 



Lectura complementaria 



Si quereis mas informacion 
sobre el IMAP4revl, consul- 
tad la obra siguiente: 

M. Crispin (1996, deciem- 
bre). RFC 2060 - Internet 
Message Access Protocol - 
Version 4revl . 



• Servidor IMAP4: recibe peticiones de los clientes IMAP4 y se las 
sirve accediendo a los buzones correspondientes. 

La figura siguiente presenta los elementos del modelo funcional del 
IMAP4 integrados en un sistema en el que se utiliza SMTP para enviar 
el correo e IMAP4 para acceder a los buzones: 
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19.4.2. Conceptos basicos del IMAP4 

El IMAP4 puede utilizarse con cualquier protocolo de transporte fia- 
ble. Por norma general, se utiliza el TCP y, en este caso, se utiliza el 
puerto 143. Todas las interacciones entre cliente y servidor se llevan 
a cabo en forma de Ifneas ASCII acabadas con un caracter <CRLF>. 



Cada comando del cliente empieza con un identificador (por lo ge- 
neral, una cadena alfanumerica corta) llamado tag. El cliente debe 
generar un tag diferente para cada comando. 



El servidor puede enviar datos tanto en respuesta a un comando del 
cliente, como de manera unilateral, y el cliente debe estar a punto 
para recibirlos en todo momento. Los datos transmitidos por el ser- 
vidor hacia el cliente y las respuestas de estatus que no implican la 
finalizacion del comando empiezan con el token. La respuesta final 
de culminacion de comando empieza con el mismo tag que el co- 
mando del cliente que ha dado lugar a la respuesta. 
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Ademas de las respuestas especfficas de cada comando, casi todos 
los comandos disponen, como mfnirno, de los resultados de estatus 
siguientes: 

OK [Parametros] : el comando se ha ejecutado. 

NO [Parametros] : el comando no se ha ejecutado. 

BAD [Parametros] : comando desconocido o argumentos invalidos . 



Nota 



Consultad el comando 
LOGOUT en el apartado 
19.4.3. 



Ejemplo 

a006 logout 

* BYE IMAP4revl server terminating connection 
a006 OK LOGOUT completed 

La primera linea es la llamada al comando precedida 
del tag (a006). En este caso, el comando LOGOUT. 
Despues, se puede observar la respuesta, que esta 
formada por dos Ifneas. La ultima linea de la res- 
puesta empieza con el mismo tag que la llamada, 
mientras que las Ifneas anteriores lo hacen con el 
token . 



El cliente puede enviar un comando despues de otro sin esperar el 
resultado del primero. De manera similar, un servidor puede empe- 
zar a procesar un comando antes de acabar de procesar el que se 
ejecuta en aquel momento. 

Ademas del texto, cada mensaje tiene asociados diferentes atributos 
que se encuentran almacenados dentro del buzon y que son son los 
siguientes: 

1) Identificador unico (UID, unique identifier ): a cada mensaje se 
le asocia un valor de 32 bits que, cuando se utiliza conjuntamente 
con los valores de validez de identificador unico ( unique identifier 
validity value), forma un valor de 64 bits que identifica de manera 
unica un mensaje dentro de un buzon. Los UID se asignan de ma- 
nera ascendente dentro del buzon, pero no necesariamente de 
manera contigua. 

2) Numero de secuencia del mensaje ( message sequence number ): 

este atributo proporciona la posicion relativa del mensaje den- 
tro del buzon, desde el 1 hasta al numero total de mensajes. 
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Esta posicion debe ordenarse siguiendo los UID ascendentes. Los nu- 
meros de secuencia del mensaje se pueden reasignar durante la se- 
sion (por ejemplo, cuando se elimina un mensaje del buzon). 

3) Indicadores: cada mensaje tiene asociada una lista de cero indi- 
cadores, o mas, que informan del estado: 

• \Seen: mensaje lefdo 

• \Answered: mensaje contestado 

• \Flagged: mensaje marcado por atencion urgente/especial 

• \Deleted: mensaje marcado para ser borrado por un Expunge 
posterior 

• \Draft: mensaje no editado del todo 

• \Recent: mensaje acabado de llegar en esta sesion 

4) Fecha interna ( internal date): fecha y hora que cada mensaje Ne- 
va asociadas de manera interna dentro del servidor, que reflejan 
cuando ha llegado el mensaje al servidor. No es la fecha del 
mensaje RFC 822. 

5) Longitud [RFC 822] ([RFC 822]s/ze): es el numero de bytes del 
mensaje expresado en el formato RFC 822. 

6) Estructura del sobre ( envelope structure): representacion anali- 
zada de la informacion del sobre RFC 822. 

7) Estructura del cuerpo (body structure): representacion analizada 
de la informacion de la estructura del cuerpo MIME. 

8) Textos de mensaje: ademas de permitir la recuperacion de los 
mensajes RFC 822 enteros, con el IMAP4 tambien se pueden efec- 
tuar recuperaciones parciales. En concreto, permite recuperar la 
cabecera y/o el cuerpo del mensaje RFC 822, una parte del cuer- 
po MIME o una cabecera MIME. 

El IMAP4 especifica cuatro estados: 

• Estado no autenticado: el cliente debe proporcionar sus creden- 
ciales. Se llega a este estado cuando se empieza una conexion, 
salvo que ya se haya preautenticado. 

• Estado autenticado: el cliente debe seleccionar un buzon al que 
accedera antes de tener permiso para efectuar comandos sobre 
los mensajes. 
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• Estado seleccionado: se entra en este estado cuando se ha selec- 
cionado con exito un buzon. 

• Estado de logout: la conexion se acaba y el servidor la cerrara. 
Se puede entrar en este estado como resultado de una peticion 
del cliente o de manera unilateral por parte del servidor. 

La figura siguiente muestra el diagrama de flujo entre los diferentes 
estados definidos por el IMAP4: 



Figura 87. 




Rechazo 
do conoxi6r> 



SELECT o SELECT o EXAMINF 
EXAMINE *in 6xito o CLOSE 




LOGOUT, shutdown o cierre de conexi6n 



mm pi 

Cada usuario tiene su correo en el servidor, depositado en un con- 
junto de buzones estructurados jerarquicamente que se pueden ma- 
nipular remotamente a traves del IMAP4. 





Nota 

Aunqueel IMAP4 utiliza la palabra buzon para identificar 
todos los sitios donde se pueden guardar mensajes, en 
realidad lo que se entiende por buzon donde se reciben 
los mensajes es la bandeja de entrada (buzon inbox), 
mientras que los otros buzones son mas bien carpetas en 
las que se clasifican estos mensajes recibidos. 
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Cada buzon se identifica por un nombre relativo, una cadena de carac- 
teres que lo diferencia de los buzones hermanos. Asimismo, cada buzon 
dispone de un nombre que lo identifica dentro de la estructura formada 
por la secuencia de los nombres relativos de los buzones que definen los 
niveles de jerarqufa superiores, de izquierda a derecha, separados con un 
unico caracter (por norma general, el caracter Debe utilizarse el mis- 
mo separador en todos los niveles de la jerarqufa dentro de un nombre. 



19.4.3. Funcionalidad del IMAP4 

La funcionalidad proporcionada por el IMAP4, como la del POP3, 
imita la que se requiere para el acceso a los buzones de correo pos- 
tal. Como mejora respecto al POP3, el IMAP4 proporciona una es- 
tructura jerarquica del buzon en forma de carpetas, asf como 
facilidades de suscripcion, lo que da lugar a nuevos comandos que 
permiten gestionar todos estos elementos. 

Las funciones que se utilizaran segun el estado en que se encuentre 
la comunicacion seran las siguientes: 

1 ) Cualquier estado (comandos/estados universales). Sea cual sea el 
estado de la conexion, se pueden utilizar los comandos siguientes: 

a) Peticion de capacidades (CAPABILITY) 

El comando CAPABILITY, que no tiene ningun argumento, sirve 
para solicitor la lista de capacidades que soporta el servidor 

CAPABILITY 



b) Operacion nula (NOOP) 

El comando NOOP permite al cliente IMAP4 averiguar si la co- 
nexion con el servidor todavfa esta abierta. 

NOOP 



c) Finalizacion de conexion (LOGOUT) 

El comando LOGOUT permite al cliente notificar al servidor que 
quiere acabar la conexion. 

LOGOUT 
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2) Estado no autenticado. En este estado, un cliente proporciona 
sus credenciales; para ello, se utilizan los comandos siguientes: 

a) Indicador de autenticacion (AUTHENTICATE) 

El comando AUTHENTICATEsirve para indicar al servidor IMAP4 
un mecanismo de autenticacion; es decir, cual de los diferentes 
mecanismos de autenticacion posibles utiliza el cliente. 

AUTHENTICATE tipo_autenticacion 



b) Identificacion de usuario (LOGIN) 

Como todo protocolo, el IMAP4 proporciona un comando para 
permitir que el cliente se identifique ante el servidor por medio del 
envfo de un identificador de usuario y una contrasena. Este co- 
mando es LOGIN. 



LOGIN id usuario contrasena 



3) Estado autenticado. En este estado el IMAP4 proporciona algu- 
nas funcionalidades nuevas: 

a) Seleccion de un buzon (SELECT) 

Una vez autenticado, el cliente IMAP4 puede seleccionar un buzon 
para acceder a sus mensajes. El comando SELECT proporciona 
esta funcionalidad. 



SELECT buzon 



Este comando, ademas de los resultados de estatus, retorna las 
respuestas obligatorias sin tag siguientes: 

FLAGS: informa de los identif icadores que se pueden 

aplicar al buzon del comando. 

EXISTS: numero de mensajes existentes en el buzon. 
RECENT: numero de mensajes con el indicador \Recent. 

Tambien puede retornar las respuestas OK sin tag: 
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NSEEN: numero del primer mensaje sin el indicador \Seen. 
PERMANENTFLAGS : lista de indicadores que pueden modificarse 
permanentemente . 



b) Examen de un buzon (EXAMINE) 



El comando EXAMINE permite un acceso al buzon similar al del 
comando SELECT, pero de manera que el buzon sea solo de lec- 
tura. Este comando, ademas de los resultados de estatus, puede 
retornar las mismas respuestas que el comando SELECT. 

EXAMINE buzon 



c) Creadon de un buzon (CREATE) 

Al usuario le puede interesar crear un buzon con un nombre de- 
terminado. El IMAP4 proporciona el comando CREATE para ello. 

CREATE buzon 



d) Borrado de un buzon (DELETE) 

El IMAP4 tambien facilita la eliminacion permanente de un buzon 
con un nombre determinado por medio del comando DELETE. 

DELETE buzon 



e) Renombramiento de un buzon (RENAME) 

En ocasiones, el usuario desea cambiar el nombre de un buzon 
por uno nuevo. El cliente IMAP4 puede solicitor esta accion al ser- 
vidor por medio del comando RENAME. 

RENAME buzon nuevobuzon 



f) Suscripcion de un buzon (SUBSCRIBE) 

En el IMAP4, no es preciso que todos los buzones esten activos a 
cada momento. Con el comando SUBSCRIBE, el nombre del bu- 
zon pasa a formar parte de la lista de buzones activos o suscritos. 

SUBSCRIBE buzon 



g) Eliminacion de la suscripcion de un buzon (UNSUBSCRIBE) 

El comando UNSUBSCRIBE permite desactivar un buzon elimi- 
nando su nombre de la lista de buzones activos o suscritos. 

UNSUBSCRIBE buzon 
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h) Listado de buzones (list) 



El comando LIST permite obtener los nombres de buzones que 
cumplen los criterios de busqueda deseados dentro de un buzon 
de referenda. 

LIST buzon 1 *criterio_busqueda 

Este comando, ademas de los resultados de estatus, puede retor- 
nar la respuesta sin fag siguiente: 

LIST:nombre del buzon que cumple los criterios 
de busqueda deseados. 

Puede haber mas de una respuesta LIST. 

i) Listado de buzones suscritos (LSUB) 

El comando LSUB permite obtener los nombres de los buzones 
activos o suscritos que cumplen los criterios de busqueda desea- 
dos dentro de un buzon de referencia. 



LSUB buzon 1 *criterio_busqueda 



Este comando, ademas de los resultados de estatus, puede retor- 
nar la respuesta sin tag siguiente: 

LSUB : nombre del buzon que cumple los criterios de busqueda 
deseados . 

Puede haber mas de una respuesta LSUB. 

j) Estado del buzon (STATUS) 

El comando STATUS permite conocer el estado de un buzon. 

Los atributos de estado definidos son los siguientes: 

• MESSAGE: numero de mensajes en el buzon. 

• RECENT: numero de mensajes con el indicador \Recent. 

• UIDNEXT: UID que se asignara al mensaje siguiente que lle- 
gue al buzon. 

• UIDVALIDITY: valor del UID del buzon. 

• UNSEEN: numero de mensajes sin el indicador \Seen. 

STATUS buzon 
(l#atributo_estado) 
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Este comando, ademas de los resultados de estatus, puede retor- 
nar la respuesta sin tag siguiente: 

STATUS: nombre de buzon que cumple el estatus deseado y 
la informacion de estatus requerida. 

k) Anadido de un mensaje al buzon (APPEND) 

El comando APPEND permite al cliente el IMAP4 anadir un texto 
literal como nuevo mensaje al final de un buzon seleccionado, 
con la fecha, la hora y los indicadores deseados. 



APPEND buzon [lista_f lags] 
[fecha_hora] literal 



4) Estado seleccionado. En el estado seleccionado, el IMAP4 pro- 
porciona nuevas funcionalidades, ademas de los comandos uni- 
versales y los del estado autenticado: 

a) Control del buzon (CHECK) 

El comando CHECK permite al cliente IMAP4 pedir al servidor un pun- 
to de control del buzon seleccionado en un momenta determinado. 

CHECK 



b) Cierre del buzon (CLOSE) 

El comando CLOSE permite cerrar un buzon seleccionado y elimi- 
nar permanentemente todos sus mensajes que tienen el indicador 

\Deleted . 

CLOSE 



c) Eliminacion de mensajes (EXPUNGE) 

El comando EXPUNGE permite eliminar de manera permanente to- 
dos los mensajes que tienen el indicador \Deleted del buzon selec- 
cionado y sin necesidad de cerrarlo. 

EXPUNGE 



Este comando, ademas de los resultados de estatus, puede retornar 
la respuesta sin tag siguiente: 

EXPUNGE: numero de secuencia de mensaje especificado que 
ha sido eliminado permanentemente. 
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d) Busqueda de mensaje (SEARCH) 

El comando SEARCH permite al cliente IMAP4 buscar dentro del 
buzon los mensajes que contienen un conjunto de caracteres es- 
pecificado y que cumplen unos criterios de busqueda deseados. 

SEARCH [CHARSET 

con j unto_carac teres] 

1 #cri terio_busqueda 

Este comando, ademas de los resultados de estatus, puede retor- 
nar la respuesta sin tag siguiente: 

SEARCH: un numero de secuencia o mas de los mensajes que 
cumplen el criterio de busqueda deseado. 

e) Recuperacion de mensajes (FETCH) 

El comando FETCH permite la recuperacion de un conjunto de 
mensajes (total o parcialmente), especificando unos atributos de 
recuperacion. 

FETCH conjunto_mensajesALL I FULL 
I FAST I 

atrib_recup I ( l#atrib_recup ) 

Este comando, ademas de los resultados de estatus, puede retor- 
nar la respuesta sin tag siguiente: 

FETCH: informacion del mensaje que presenta los atributos 
de recuperacion especificados . 

f) Modificacion de almacen (STORE) 

El comando STORE permite modificar los indicadores del almacen 
que proporcionan los atributos a un conjunto de mensajes del buzon. 

STORE conjunto_mensajes 

indicadores_atrib_almacen 

Este comando, ademas de los resultados de estatus, puede retor- 
nar la respuesta sin tag siguiente: 

FETCH: informacion de los mensajes. 



g) Copia de mensaje(s) (COPY) 

El comando COPY permite copiar un conjunto de mensajes al final 
de un buzon especificado. 

COPY con j unto_mensaj es buzon 
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h) Retorno de identificador unico (UID) 



La sentencia UID, seguida de los parametros COPY, FETCH, STO- 
RE o SEARCH, en lugar de retornar el numero o numeros de se- 
cuencia de mensaje, retorna sus identificadores unicos. 



UID (COPY . . 


. | FETCH ... | 


SEARCH . . . 


I STORE . . . ) 



Este comando, ademas de los resultados de estatus, puede retor- 
nar las respuestas sin tag siguientes: 

FETCH: informacion del mensaje que presenta los atributos 
de recuperacion especif icados . 

SEARCH: un UID o mas indican los mensajes que cumplen el 
criterio de busqueda deseado. 

5) Experimental/expansion 



Comando experimental (X<atom>) 

El IMAP4 permite especificar comandos experimentales que no son 
una parte de la especificacion, siempre que su nombre empiece con 
el prefijo X. 



XI *caracter 



19.4.4. Ejemplo 

A continuacion, se presenta un ejemplo de los comandos de un clien- 
te IMAP4 (en negrita) que accede a un servidor IMAP4 para entrar en 
sus buzones. En el ejemplo se ve como se recupera la informacion 
del mensaje 1 2 (fetch 12 full). En la informacion retornada por 
el servidor, se ve la informacion "parseada" de la cabecera. A conti- 
nuacion, se recupera toda la cabecera del mismo mensaje 
(fetchl2 body [header ]). Al final, antes de cerrar la conexion, 
se marca el mensaje para que sea borrado. 

* OK IMAP4revl Service Ready 

aOOl login rmarti secret 

aOOl OK LOGIN completed 

a002 select inbox 

* 18 EXISTS 

* FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 

* 2 RECENT 
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* OK [UNSEEN 17] Message 17 is the first unseen message 

* OK [UIDVALIDITY 3857529045] UIDs valid 
a002 OK [READ-WRITE] SELECT completed 

a003 fetch 12 full 

* 12 FETCH (FLAGS (\Seen) INTERNALDATE " 2 7 - Jun-2 0 03 
02:44:25 -0700" RFC 822. SIZE 4286 ENVELOPE 

("Fri, 27 Jun 2003 02:23:25 -0700 (PDT) " 

"Ejemplo de acceso IMAP4revl" 



( (' 


'Jordi 


Inyigo" 


NIL 


" j inyigo" 


"uoc . edu' 


'> > 


( (' 


'Jordi 


Inyigo" 


NIL 


" j inyigo" 


"uoc . edu' 


n > 


( (' 


'Jordi 


Inyigo" 


NIL 


" j inyigo" 







((NIL NIL " rmarti" "uoc.edu") ) 

((NIL NIL "xperramon" "uoc.edu") 

("JM Marques" NIL " jmmarques " "uoc.edu")) 

NIL NIL 

"<B27397-0100000@uoc.edu>") 

BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL 
" 7BIT" 3028 92 ) ) 
a003 OK FETCH completed 
a004 fetch 12 body [header] 

* 12 FETCH (BODY [HEADER] {350} 

Date: Fri, 27 Jun 2003 02:23:25 -0700 (PDT) 

From: Jordi Inyigo < j inyigo@uoc . edu> 

Subject: Ejemplo de acceso IMAP4revl 
To: rmarti@uoc.edu 
cc: xperramon@uoc.edu, 

JM Marques < jmmarques@uoc . edu> 

Mess age -Id: <B27397-0100000@uoc. edu> 

MIME-Version : 1.0 

Content-Type: TEXT/PLAIN; CHARSET=US-ASCI I 

) 

a004 OK FETCH completed 

a005 store 12 +flags \deleted 

* 12 FETCH (FLAGS (\Seen \Deleted) ) 
a005 OK +FLAGS completed 

a006 logout 

* BYE IMAP4revl server terminating connection 
aOO 6 OK LOGOUT completed 



19.5. Extensiones multimedia: el formato MIME 

La norma RFC 822 define un formato de mensaje y un contenido con una 
unica parte de texto en ASCII de 7 bits. Se vio que este formato era muy 
pobre y que se precisaba algun metodo para superar sus limitaciones. 

El formato MIME ( multipurpose Internet mail extensions ) redefine el 
formato del mensaje para permitir, sin perder la compatibilidad con 
el formato definido por el RFC 822, las caracterfsticas siguientes: 

• Contenido de texto no solo ASCII de 7 bits. 

• Contenido no texto. 

• Contenido con multiples partes. 

• Cabeceras con texto no solo ASCII de 7 bits. 
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19.5.1. Nuevos compos de cabecera 



Para permitir todas las nuevas extensiones, el MIME define nuevos 
campos de cabecera: MIME -Version, Content-Type, Content - 
Transfer-Encoding, Content-ID y Content-Description. 



Indicador de version (MIME-Version) 

El campo de cabecera MIME-Version indica la version MIME que 
se utiliza en el mensaje (la version de MIME que se utiliza actualmen- 
te, y que especificamos en este apartado, es la 1 .0.). Este campo es 
util para que el receptor del mensaje pueda interpretar los campos 
de cabecera MIME. 

MIME-Version: l*digit. l*digit 



Indicador del tipo y subtipo de datos (Content-Type) 

El campo de cabecera Content-Type permite indicar los tipos y 
subtipos de los datos que se encuentran dentro del mensaje. De 
este modo, el receptor podra conocer los tipos de datos que conve- 
ne el mensaje y podra visualizarlos adecuadamente. Segun el tipo 
o subtipo de dato, puede incluir algun parametro adicional. 

Content-Type: tipo/subtipo *(; parametro) 
tipo = tipo-discreto | tipo-compuesto 
tipo-discreto = text | image I audio I video I 
application | extension-token 
tipo-compuesto = message I multipart I 
extension-token 




Para obtener mas informacion sobre el formato de 
mensajes MIME, podeis consultar las obras siguientes: 



N. Freed; N. Borenstein (1996, noviembre). RFC 
2045 - Multipurpose Internet Mail Extensions (MIME) 
Part One: Format of Internet Message Bodies. 
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N. Freed; N. Borenstein (1996, noviembre). RFC 
2046 - Multipurpose Internet Mail Extensions (MIME) 

Part Two: Media Types. 

K. Moore (1996, noviembre). RFC 2047 - MIME 
(Multipurpose Internet Mail Extensions) Part Three: 
Message Header 
Extensions for Non-ASCII Text. 

N. Freed; J. Klensin; J. Postel (1996, noviembre). RFC 

2048 - Multipurpose Internet Mail Extensions (MIME) 

Part Four: Registration Procedures. 

N. Freed; N. Borenstein (1996, noviembre). RFC 

2049 - Multipurpose Internet Mail Extensions (MIME) 

Part Five: Conformance Criteria and Examples. 

La norma define cinco tipos de contenido (tipo-discreto), con 
los subtipos correspondientes. Estos tipos corresponden a datos mo- 
nomedia: 

• text: para informacion de texto. 

• image: para imagenes. 

• audio: para sonido. 

• video: para video. 

• application: para cualquier otro tipo de datos, por norma ge- 
neral en formato especffico de alguna aplicacion. 

La norma tambien define dos tipos de datos compuestos ( tipo - 
compuestdj : 

• multipart: para datos formados de muchas partes o para da- 
tos independientes dentro de un mismo mensaje. 



Nota 

En los mensajes de tipo multipart, el parametro 
boundary incluye una cadena, precedida por dos ca- 
racteres de guion, que se utiliza como separador 
entre las diferentes partes del mensaje. 
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Para indicar que se han acabado todas las partes, se 
utiliza la cadena del para metro boundary, precedida y 
seguida de dos caracteres de guion, 

• message: para encapsular otro mensaje dentro del mensaje. 

La tabla siguiente presenta los valores de tipo, subtipo y parametros 
para los Content-Type definidos en la norma: 



Tabla 13. 



Valores definidos para Content-Type 









text 


plain 


charset = ISO-8859- (1 ... | 9) us-ASCII 


enriched 


charset = ISO-8859- (1 ... | 9) us-ASCII 


image 


gif 


- 


jpeg 


- 


audio 


basic 


- 


video 


mpeg 


quicktime 


application 


octet-stream 


type = cadena; 
padding = entero 


postscript 


- 


multipart 


mixed 


boundary = cadena 


alternative 


boundary = cadena 


parallel 


boundary = cadena 


digest 


boundary = cadena 


message 


rfc 822 


- 


partial 


id = cadena ; 
number = entero 
[; total = entero ] 


external -body 


access-type = ftp | anon-ftp | tftp | 
afs | local-file I mail-server 
[/expiration = date-time ] 

[/size = entero ] 

[ /permission=read | read-write] 

[ / name = cadena ] 

[/site = cadena ] 

[/dir = cadena ] 

[/mode = netascii | octet | mail | 
ascii | ebcdic | image | localn ] 
[/server = cadena ] 

[/subject = cadena ] 
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Especificador del tipo de codificacion (Zontent-Transfer- 
Encoding) 

En algunos protocolos, como el SMTP, la informacion que se envfa 
debe ser en ASCII de 7 bits. En ocasiones, los datos originales no ten- 
dran este formato y, entonces, sera preciso aplicarles algun tipo de 
codificacion antes de enviarlos. 

El campo de cabecera Content-Transfer-Encoding sirve para 
especificar el tipo de codificacion que se ha aplicado al contenido del 
mensaje para que el receptor pueda descodificarlo, si es preciso. La 
norma define diferentes tipos de codificacion: 



Content-Transfer-Encoding : mecanismo 

mecanismo = 7bit | 8bit | binary | quoted-printable | base64 



a) Codificacion 7bit | 8bit | binary 

Los mecanismos de codificacion 7bit, 8bit y binary solo sirven 
para indicar de que tipo son los datos transmitidos. En estos casos, 
los datos no se codifican y, por norma general, se utilizan para apli- 
caciones que no restringen la representacion de datos en 8 bits. 

b) Codificacion quoted-printable 

El mecanismo de codificacion quoted-printable se utiliza para la 
representacion y codificacion en ASCII de 7 bits de datos, la mayorfa de 
los cuales ya es de bytes representables en este formato. Es decir, este 
mecanismo se aplica cuando la informacion es mayoritariamente de ca- 
racteres de texto. Las normas basicas de codificacion son las siguientes: 

• Cualquier byte se puede representor con el caracter "=" seguido 
por la notacion hexadecimal en dos dfgitos (y letras en mayuscula) 
del valor del byte. 

• Los bytes con valores decimoles entre 33-60 y 62-126, inclufdos los 
cuatro, se pueden representor con el caracter ASCII correspondiente. 

c) Codificacion Base64 

El mecanismo de codificacion Base64 ofrece una codificacion de in- 
formacion binaria en ASCII de 7 bits que no deba ser legible. Los al- 
goritmos de codificacion y descodificacion son muy simples. 



El proceso de codificacion se lleva a cabo tomando grupos de 3 bytes 
(24 bits). Manteniendo el orden de bits original, estos 24 bits se re- 
agrupan en 4 bloques de 6 bits (6 bits = 64 combinaciones). 

El fichero codificado se obtiene tomando cada uno de estos bloques 
de 6 bits y codificandolo como un caracter alfanumerico a partir del 
valor binario de los 6 bits, segun la tabla siguiente: 



Nota 



La codificacion de datos en 
Base64 utiliza 4 caracteres 
para cada 3 bytes. Por este 
motivo, Base64 aumenta el 
tamano de la information un 
33% (4/3). 



Tabla 14. 



Tabla de codificacion Base64 










0 'A' 

1 'B' 

25 'Z' 


26 'a' 

51 'z' 


52 '0' 

61 '9' 


62 '+' 

63 '/' 

pad 



Nota 

Si debe codificarse un numero de bytes que no sea 
multiplo de 3 (la codificacion, portanto, no serfa mul- 
tiplo de 4 bytes), se codifican todos los bytes y, al final 
de la cadena de caracteres ya codificada, se anaden 
tantos caracteres "=" (caracter para rellenar, pad ) 
como sean necesarios (maximo dos) hasta llegar a un 
numero de caracteres multiplo de 4. 

En el proceso de descodificacion, se toman los caracteres alfanume- 
ricos recibidos y se reconvierten en su valor binario correspondiente 
(6 bits) segun la tabla. Cada 4 caracteres recibidos dan lugar a 24 
bits, y solo es preciso irlos reagrupando en 3 bytes para generar el 
fichero descodificado. Antes de descodificar todo el mensaje, es pre- 
ciso eliminar todos los caracteres "=" que se encuentren al final. 



Identificador del contenido del mensaje (Content-ID) 

El campo de cabecera Content-ID se utiliza para proporcionar un 
identificador unico al contenido del mensaje. Con dicho identifica- 
dor, se hace referencia al contenido de manera no ambigua. 

Content-ID: id-msg 
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So 



ore 



Informador descriptivo del contenido 
(Content-Description) 

El campo Content-Description proporciona informacion des- 
criptiva del contenido en forma de texto. 

Content-Description: texto 



19.5.2. Extensiones para texto no ASCII 
en las cabeceras 



El MIME tambien permite codificar texto no ASCII en las cabeceras de 
los mensajes RFC 822 de manera no ambigua. Este metodo permite 
codificar toda la cabecera o solo una parte. El texto (que puede ser 
de mas de un caracter) ya codificado, precedido por el conjunto de 
caracteres y un identificador del tipo de codificacion que se ha apli- 
cado, se incluye en el lugar correspondiente de la cabecera entre los 
caracteres "=?" y 

=? charset ? codificacion ? texto-codif icado ?= 
charset = ISO-8859- (1 ... j 9) us-ASCII 

codificacion = Q | B 



Nota 

a) Conjunto de caracteres (charset): es valido cualquiera 
de los caracteres permitidos en el Content-Type 
text/plain. 

b) Codificaciones : el formato MIME permite dos tipos 
de codificacion similares a las codificaciones que 
se pueden aplicar al cuerpo del mensaje: 

• Q: es parecida al Content-Transfer-Encoding 
quoted-printable. Es la que se recomienda 
cuando la mayorfa de los caracteres que deben 
codificarse son ASCII. 

• B: es identica al Content-Transfer-Encoding 

Base64. Es adecuada para el resto de casos. 
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19.5.3. Mensajes multiparte 



En los mensajes multiparte, cada una de las partes suele estar for- 
mada por una pequena cabecera y el contenido. En la cabecera se 
pueden encontrar los campos Content-Type, Content-Trans- 
fer-Encoding, Content-IDy Content-Description. Todos 
se refieren al contenido de la parte en cuestion. 



1 9.5.4. Ejemplo 



En este ejemplo se puede contemplar un mensaje RFC 822 con ex- 
tensiones MIME version 1 .0. Es un mensaje de dos partes: la prime- 
ra es de texto codificado con quoted-printable y la segunda es 
una imagen en formato .gif codificada en Base64. Asimismo, se 
puede ver un campo de cabecera con una letra i codificada con co- 
dificacion Q. 



Date: 27 Jun 2003 0932 PDT 

From: Jordi Inyigo < j inyigo0uoc . edu> 

To: Ramon =?iso-8 8 59-1 ?Q?Mart=ED? = 

<rmarti0uoc . edu> 

MIME -Version: 1.0 
Content-Type: multipart/mixed; 
boundary="=_2 50 69 9_" 

— =_250699_ 

Content-Type: text/plain; charset="iso-8 85 9-1 " 
Content-Transfer-Encoding : quoted-printable 

Esto es un mensaje RFC 822 que contiene MIME. 

— =_250699_ 

Content-Type: image/gif; name="Readme . gif " 
Content- Transfer-Encoding : base 6 4 

ROlGODlhl AAgA I AAAAAAAP / / / y H 5 B AE AAAAALAAAAAAg AC AAA 
AJz j I+pywoQXoSywoaontzeRhnXKJYc82GOuaoL2br Jlx7pg+ 
eSzc9yHAHqhpmi8ddLspCT3Y2pXNZ+UxpUpGNNZVsYdBsMf 41 
BsMocuqLFyCH05I6/MWY2sy7PL4F3+nU/kxcHePT191dnR+WS 
yAcimGVQAAA7 

— = 250699 — 



Nota 



La "f de Ramon Marti se ha 
codificado con codificacion Q 
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20. Servicio de noticias: el NNTP 



El servicio de noticias (en ingles, news) permite el envfo de mensa- 
jes, como el servicio de correo electronico, pero con la diferencia 
de que el originador no especifica el destinatario o destinatarios, 
sino que cualquier usuario con acceso al servicio puede leerlos. 
Esta funcionalidad, pues, se puede comparar a la de un tablon de 
anuncios, en el que todo el mundo puede leer los mensajes que se 
encuentran colgados. 



El servicio de noticias en Internet se conoce con el nombre Usenet, 
que proviene del de la red en que se desarrollo originariamente 
este servicio. En la actualidad, la distribucion de noticias se ha ex- 
tendido por todo Internet, de manera que los anuncios enviados se 
pueden leer en cualquier parte del mundo. En la practica, sin em- 
bargo, es posible restringir el ambito en que se quiere distribuir los 
mensajes, puesto que algunos solo seran interesantes, por ejemplo, 
en una determinada zona geografica. 



20.1. El modelo NNTP 



En el servicio de noticias, la distribucion de los mensajes o anuncios, 
que en Usenet se denominan articulos, se efectua de manera des- 
centralizada. Teniendo en cuenta el enorme volumen de trafico que 
genera este servicio, no serfa viable tener un servidor central en el 
que todo el mundo dejara sus articulos y fuera a leer los de los de- 
mos. Por este motivo, se utiliza un mecanismo de propagacion en el 
que el autor de un articulo lo envia a un servidor de noticias, el cual 
se encargara de reenviarlo a una serie de servidores proximos o con 
los que este conectado directamente, que a su vez lo reenviaran a 
otros servidores, y asi sucesivamente. 

Con este mecanismo de propagacion, se consigue que un articulo 
este disponible para ser leido, idealmente, en todos los servidores de 
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la red. Los usuarios que deseen leer los artfculos podran hacerlo, 
pues, conectandose a cualquier servidor, preferiblemente al que ten- 
gan mas proximo. 



Por otro lado, los servidores solo almacenan coda artfculo durante 
cierto tiempo. Hay artfculos que tienen una fecha de caducidad pre- 
determinada, y el servidor los borra automaticamente en la misma. 
Otros se borran, por ejemplo, cuando el servidor decide que los 
usuarios que puedan estar interesados en los mismos ya han tenido 
bastante tiempo para leerlos. 



Lectura complementaria 



Si quereis mas informacion 
sobre el NNTP, consultad la 
obra siguiente: 

B. Kantor; P. Lapsley 
(1986, tebrero). RFC 977 - 
Network News Transfer 
Protocol. 



El metodo utilizado para propagar los artfculos tiene ciertas limi- 
taciones; por ejemplo, no se puede garantizar que un artfculo lle- 
gue a todos los servidores en un plazo determinado (o, en ocasiones, 
que llegue a un servidor concreto), es preciso controlar el camino por 
donde pasa coda artfculo para evitar bucles, etc. Sin embargo, 
este metodo es mas practico y eficiente que la solucion de un solo 
servidor central. 



Los servidores de noticias se comunican entre sf para intercambiarse 
artfculos por medio del NNTP (network news transfer protocol ), espe- 
cificado en el documento RFC 977. 



Nota 



Antiguamente se utilizaban 
otros metodos de transmi- 
sion de artfculos entre servi- 
dores, como el UUCP ( Unix 
to Unix copy protocol ). 



Nota 

Un usuario que desee acceder al servicio, tanto 
para enviar artfculos como para leerlos, puede ser 
que tenga acceso directo a alguno de los servidores 
de noticias. En este caso, la comunicacion con el 
servidor es un asunto local. El caso mas general, sin 
embargo, es que el usuario quiera acceder al servi- 
cio desde otro sistema, caso en que dicho sistema 
actuara como cliente. Entonces, la comunicacion 
entre el cliente y el servidor se Neva a cabo tambien 
por medio del NNTP. 



Tanto si se trata de un cliente local, como de un cliente remoto, 
por norma general habra otro proceso encargado de la interfaz 
con el usuario. Este tipo de programa se suele llamar lector de 
noticias. 
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Asimismo, existe la posibilidad de que un grupo de clientes acceda a 
un servidor central de una organizacion por medio de un servidor es- 
clavo: 




Nota 

El servidor esclavo puede mejorar la eficiencia en el 
acceso, por ejemplo, almacenando localmente copias 
de los ultimos artfculos lefdos, por si los solicitan otros 
clientes. 



Los artfculos disponibles en un servidor deben estar organizados en 
grupos, segun su tema, para facilitar el acceso a los usuarios que 
quieran leerlos. Esta organizacion sigue un modelo jerarquico: en el 
nivel mas alto de los grupos se encuentran los temas generales que, 
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en un segundo nivel, estan divididos en subtemas, los cuales, a su 
vez, pueden estar subdivididos en niveles inferiores. 



Nota 

Es posible que un mismo articulo pertenezca a mas de 
un grupo. Cuando un usuario envfa un artfculo al sis- 
tema de noticias, ademas de poder especificar en que 
ambito se debe distribuir, es preciso que indique obli- 
gatoriamente a que grupo o grupos lo quiere enviar. 



La nomenclatura que se utiliza para designar los grupos consiste en con- 
catenar los nombres de cada nivel, de mas alto a mas bajo, separando- 

los con “ . " (por ejemplo, news . announce O comp, os . linux . hardware). 

En el nivel mas alto de la jerarqufa, los grupos originales de Use- 
net eran los siguientes: 

• comp: temas relacionados con ordenadores e informatica. 

• news: artfculos sobre el sistema de noticias mismo. 

• rec: actividades recreativas, hobbies, etc. 

• soc: temas sociales, culturales, humanfsticos, etc. 

• sci: temas cientfficos. 



Nota 



Actualmente, existen otros 
grupos del nivel superior, 
como los que solo contienen 
artfculos destinados a una 
region geografica. Por 
ejemplo eu para Europa, 
es para Espaha, fr para 
Francia, etc. 



• talk: debates, discusiones, opiniones, etc. 

• misc: otros temas no clasificables en los apartados anteriores. 

• alt: la jerarqufa alternative, que algunos aprovechan para sal- 
tarse las normas establecidas en los grupos "oficiales". 

En la comunidad Usenet se han establecido una serie de reglas, ba- 
sadas en un sistema de votaciones, para decidir la creacion de nue- 
vos grupos o la eliminacion de alguno de los ya existentes. Este 
caracter de democracia asamblearia, y otros aspectos como la posi- 
bilidad de publicar escritos (fotograffas, videos, etc.) o dar a conocer 
las ideas de una persona de manera global y casi instantanea (un 
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sueno que, hasta la llegada de Internet, solo estaba al alcance de los 
grandes medios de comunicacion), hicieron de Usenet el gran feno- 
meno sociologico de Internet durante unos cuantos anos. 

Hoy dfa el servicio Usenet esta eclipsado por la enorme popularidad 
del servicio WWW, que tiene una orientacion mucho mas comercial, 
pero no es tan participative. 



20.2. Conceptos bdsicos del NNTP 



Por norma general, el NNTP utiliza el protocolo de transporte TCP. El 
numero de puerto asignado al servicio de noticias es el 11 9. 



En el NNTP, se utiliza un esquema de peticiones y respuestas como 
el del SMTP. Coda peticion constituye una Ifnea acabada con 
<CRLF> que contiene un comando, posiblemente con parametros. 

Las respuestas tambien siguen la estructura general utilizada en el 
FTP o el SMTP. Cada respuestase representa con una Ifnea que em- 
pieza con un codigo numerico de tres dfgitos. A continuacion, segun 
el codigo de respuesta, puede haber una serie de parametros segui- 
dos de un texto arbitrario opcional, hasta el final de la Ifnea, que 
acaba con <CRLF>. 



Nota 



La especificacion NNTP es- 
tablece que las Ifneas de co- 
mandos no deben tener 
mas de 512 caracteres. Por 
otro lado, los comandos y 
los parametros se pueden 
escribir indistintamente en 
mayusculas o minusculas. 



Los significados del primer dfgito del codigo de respuesta son simi- 
lares a los del FTP y el SMTP; los del segundo son los siguientes: 

• xOx: respuesta referente a la conexion, inicializacion, etc. 

• xlx: seleccion de un grupo de noticias. 

• x2x: seleccion de un artfculo. 

• x3x: distribucion de artfculos. 

• x4x: envfo de artfculos. 

• x8x: extensiones no estandar. 

• x9x: mensajes informativos de prueba ( debugging ). 



Nota 



Vease el anexo 4. 



Algunas respuestas van seguidas de un texto formado por una se- 
cuencia de Ifneas. En este caso, cada Ifnea acaba con <CRLF>, y 
el final de la secuencia se indica con una Ifnea en la que solo se 
encuentra el caracter antes de <CRLF>. Si alguna de las If- 
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neas de la respuesta debe empezar con ". ", el emisor inserta otro 
al principio de la Ifnea y, por consiguiente, el receptor debe eli- 
minar todos los iniciales que encuentre antes del final de la 
respuesta. 

Cuando el cliente establece la conexion, el servidor responde con un 
codigo 200 6 201 para indicar que permite que el cliente envfe artf- 
culos o que no lo permite, respectivamente. 



20.3. Formato de los articulos 



Lectura complementaria 



Si quereis mas informacion 
sobre el formato de los arti- 
culos Usenet, consultad la 
obra siguiente: 

M.R. Horton; R. Adams 
(1987, diciembre). RFC 1036 
- Standard for interchange of 
USENET messages. 



El formato de los articulos Usenet esta definido en la especificacion 
RFC 1 036, y se basa en el de los mensajes de correo electronico (de- 
finido en la especificacion 822), aunque con algunas restricciones 
adicionales. Portanto, cada artlculo consta de una cabecera forma- 
da por una serie de campos, y de un cuerpo separado de la misma 
por una Ifnea en bianco. 

Hay seiscampos obligatorios en la cabecera, que son los que se ex- 
ponen a continuacion: 



• From: direccion de correo electronico del originador del artfculo 
(y, opcionalmente, tambien su nombre). 

• Date: dfa y hora en que se ha originado el artfculo. 

• Newsgroups: lista de los grupos a los que se envfa el artfculo, 
separados por comas si hay mas de uno. 

• Subject: asunto del que trata el artfculo, que se utilizara como 
tftulo. 

• Message-ID: identificador unico del artfculo. Aparte de este 
identificador unico, para facilitar el acceso a los articulos, cada 
servidor les asigna un identificador local consistente en el nombre 
del grupo y un numero correlativo dentro del grupo. Por lo tanto, 
si un artfculo se ha enviado a diferentes grupos, tendra mas de un 
identificador. Dichos identificadores solo son significativos para 
un servidor, puesto que otro servidor probablemente asignara 
identificadores locales diferentes a los mismos articulos. 
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• Path: lista de servidores por los que ha pasado el articulo, sepa- 
rados con simbolos de puntuacion que no sean " (por norma 
general, se utiliza el caracter " !"). Cada servidor debe anadir su 
nombre al principio de la lista. El valor de este campo permite que 
un servidor sepa si el articulo ya ha pasado por otro servidor y, 
por tanto, no es preciso volverselo a enviar. 

Asimismo, la cabecera de un articulo puede incluir los campos op- 

cionales siguientes: 

• Reply-To: direccion a la que deben enviarse los mensajes de correo 
en respuesta al articulo (por defecto, la misma del campo From). 

• Sender: identificacion del usuario que ha enviado el articulo al 
sistema de noticias, si no coincide con el del campo From. 

• Followup-To : lista de grupos de noticias, separados por comas, 
a los que deben enviarse los articulos de respuesta (por defecto, 
los mismos del campo Newsgroups). 

• Expires : fecha y hora en que el articulo se puede considerar ca- 
ducado y, por tanto, puede ser borrado por los servidores (en au- 
sencia de este campo, el servidor decide cuando los borrara). 

• References: lista de identificadores de otros articulos a los que 
se hace referencia en el articulo. 

• Control: sirve para indicar que el articulo contiene un mensaje 
de control del sistema de noticias. El mensaje se especifica en el 
valor de este campo y solo es interesante para los servidores (los 
usuarios no necesitan leer estos articulos). Los mensajes de con- 
trol sirven para cancelar articulos, crear y borrar grupos, informar 
de que articulos tiene un servidor y cuales pide otro, etc. 

• Distribution: lista de distribuciones a la que se debe enviar el 
articulo. Cada distribucion es un conjunto de servidores que, por 
norma general, pertenecen a una misma area geografica, una 
misma organizacion, etc. 

• Organization: nombre de la organizacion (empresa, institu- 
cion, etc.) a la que pertenece el originador del articulo. 

• Keywords: lista de palabras clave relacionadas con el contenido 
del articulo. 
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• Summary: breve resumen del contenido del artfculo. 

• Approved: algunos grupos de noticias son moderados, lo que sig- 
nified que los usuarios no pueden enviar los artfculos directamente. 
En este caso, los artfculos deben enviarse por correo electronico a 
una persona, llamada moderador del grupo, que es la unica que 
esta autorizada para poner artfculos en el grupo. De la totalidad de 
mensajes que recibe, el moderador decide cuales envfa al grupo y 
cuales no. Los mensajes que finalmente se envfan deben llevar en el 
campo Approved la direccion de correo del moderador. 

• Lines: numero de Ifneas del cuerpo del artfculo. 

• Xref : este campo lo genera cada servidor y no debe transmitirse 
de un servidor a otro. Contiene el nombre del servidor y una lista 
de identificadores locales que tiene el mismo artfculo en otros gru- 
pos a los que se haya enviado. Una vez que el usuario ha lefdo el 
artfculo, este campo permite a los lectores de noticias marcarlo 
como lefdo en todos los grupos en que aparezea. 

La especificacion RFC 1036 permite que la cabecera incluya otros 

campos no estandar. 



Ejemplo 

Ejemplo de artfculo Usenet 

From: usuari0acme.com (Ernest Udiant) 
Path : News . uoc . es ! news . rediris . es ! 
news .eu.net! news feed . omninet . 
org ! nntp . acme . com ! usuari 
Newsgroups: soc . culture . espanol 
Subject: Nuevo libro de recetas tradi- 

cionales 

Message-ID : <Kvj sSAam9Ly0acme . com> 

Date: Thu, 12 Dec 2002 09:12:30 GMT 
Expires: Sat, 19 Dec 2002 00:00:00 GMT 
Organization: ACME Inc. 

Lines : 2 

La semana que viene se publicara un nuevo 
libro de recetas de cocina tradicional. 
Seguiremos informando . . . 
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20.4. Comandos del NNTP 

A continuacion, se detallan los comandos definidos en la especifica- 
cion RFC 977 del NNTP: 

1) Listar grupos (LIST) 

Este comando sirve para obtener una lista de los grupos de noticias dis- 
ponibles. El servidor responde con un codigo 21 5 y, a continuacion, en- 
vfa una secuencia de lineas (acabada con " . "), una para cada grupo de 
noticias disponible, cada una con el formato siguiente: 



Nota 



Consultad la tabla de los 
codigos de respuesta al fi- 
nal de este subapartado. 



grupo ultimo primero permiso 



Nota 

• grupo: nombre del grupo. 

• ultimo: numero correlativo (identificador local) 
del ultimo artfculo que hay en este grupo. 

• primero: numero del primer artfculo. 

• permiso: puede ser y o n para indicar si se pueden 
enviar artfculos a este grupo, o no, respectivamente. 



LIST 



2) Seleccionar un grupo (GROUP) 

Este comando permite seleccionar un grupo concreto. El servidor en- 
vfa una respuesta 211 con los parametros siguientes (por este or- 
den): numero estimado de artfculos del grupo, numero del primer 
artfculo, numero del ultimo y nombre del grupo. Si el grupo no existe, 
la respuesta es 41 1 . 



Nota 

El numero de artfculos que hay en el grupo no tiene 
por que coincidir con la diferencia entre el numero del 
ultimo artfculo y el anterior al primero, puesto que 
puede ser que se hayan borrado artfculos intermedios. 



GROUP grup 
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3) Leer el artfculo (ARTICLE) 



El parametro puede ser un identificador unico de artfculo o un nume- 
ro de artfculo dentro del grupo actualmente seleccionado (el artfculo 
lefdo pasa a ser considerado como el artfculo actual). Sin parametro, 
este comando lee el artfculo actual. El servidor responde con un co- 
digo 220 seguido de dos parametros: el numero del artfculo y su 
identificador unico. A continuacion, envfa el contenido del artfculo 
(cabecera y cuerpo), acabado en Si hay algun error, el servidor 
responde con los codigos 412, 420, 423 o 430, segun el caso. 



ARTICLE [ < identificador > \ 
numero] 



4) Leer la cabecera (HEAD) 

Este comando es identico a ARTICLE; sin embargo, el servidor solo 
devuelve la cabecera del artfculo. El codigo de respuesta sera el 221 
en lugar del 220, con los mismos parametros. 



HEAD [ < identificador > \ 
numero] 



5) Leer el cuerpo (BODY) 

Este comando es identico a ARTICLE; sin embargo, el servidor solo 
devuelve el cuerpo del artfculo. El codigo de respuesta sera el 222 en 
lugar del 220, con los mismos parametros. 



BODY [ < identificador > \ 
numero] 



6) Obtener el estatus (STAT) 

Este comando es identico a ARTICLE; sin embargo, el servidor no 
devuelve ningun texto, sino solo la Ifnea de respuesta. El codigo sera 
el 223 en lugar del 220, con los mismos parametros. 



STAT [ < identificador > \ 
numero] 



7) Seleccionar el artfculo siguiente (NEXT) 

Este comando selecciona el artfculo siguiente del grupo y hace que 
pase a ser considerado el artfculo actual (es decir, lo que se leera si 
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se envfa el comando llamado ARTICLE sin parametro). El codigo de 
respuesta normal sera el 223, como en el comando STAT. Un codi- 
go de error especffico es el 421 . 



NEXT 



8) Seleccionar el artfculo anterior (LAST) 

Este comando selecciona el artfculo anterior al actual. Los codigos de 
respuesta son como los del comando NEXT, pero cambiando el 421 
por el 422. 



LAST 



9) Listar grupos nuevos (NEWGROUPS) 

NEWGROUPS dispone de las mismas funciones que el comando 
LIST, excepto que el codigo de respuesta es 231 (en lugar de 215) 
y la lista de grupos esta restringida a los que se han creado despues 
de la fecha indicada por los parametros (el primero son seis dfgitos 
que representan ano, mes y dfa, y el segundo, seis mas que repre- 
sentan hora, minutos y segundos). Opcionalmente, se puede restrin- 
gir todavfa mas la lista especificando una o mas jerarqufas de alto 
nivel separadas por comas (por ejemplo, news, rec, etc.). 



NEWGROUPS aammdd hhmmss 
[GMT] [< jerarquias >] 



10) Listar artfculos nuevos (NEWNEWS) 

El servidor responde a este comando con un codigo 230 y, a conti- 
nuacion, envfa una secuencia de Ifneas (acabada con "), una para 
cada artfculo de los grupos especificados en el primer parametro que 
se haya enviado o recibido despues de la fecha indicada por el se- 
gundo y el tercero. Las Ifneas contienen los identificadores unicos de 
los artfculos. 



NEWNEWS grups aammdd hhmmss 
[GMT] [< jerarquias >] 



El primer parametro es un nombre de grupo o una lista de nombres 
separados por comas. En un nombre, puede aparecer el caracter es- 
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pedal En este caso, se considera que equivale a todos los nom- 
bres de grupos que, en lugar del tengan una secuencia 

cualquiera de caracteres, que puede incluir el separador (Por 
ejemplo, alt. biz* puede equivaler a alt . biz . misc, alt. bi- 
zarre, etc.). Por otro lado, si un nombre tiene el p ref i j o " ! ", el grupo o 
grupos correspondientes se excluiran de la lista (por ejemplo, 
comp . lang . * , ! comp . lang . c . * equivale a los grupos que em- 

piecen por comp . lang., pero no por comp . lang . c .). 

Opcionalmente, se puede restringir la lista de artfculos a un conjunto 
de una o mas jerarqufas si se especifican en el ultimo parametro se- 
paradas por comas. La lista solo contendra artfculos que pertenez- 
can al menos a un grupo de las jerarqufas. 

11) Enviar un artfculo (POST) 

Este comando se utiliza para enviar un artfculo. El servidor responde 
con un codigo 440 para indicar que no se permite la operacion, o 
con un 340 para solicitor el artfculo. En el segundo caso, el cliente 
debe enviar el contenido del artfculo (cabecera y cuerpo) con el for- 
mato definido en la especificacion RFC 1 036 y acabado con una Ifnea 
en que solo haya un Entonces, el servidor enviara la respuesta de- 
finitive, que sera 240 o, si ha habido algun error, 441 . 



POST 



12) Ofrecer un artfculo (IHAVE) 



Cuando un servidor se conecta a otro, puede utilizar el comando 
IHAVE para hacerle saber de que artfculos dispone. 



Nota 



Un servidor no deberfa ofre- 
cer a otro servidor artfculos 
que ya le haya enviado antes 
o que ya hayan pasado por 
este ultimo (el campo Path 
de la cabecera lo indica). 

Esta situacion se conoce 
como doble ofrecimiento. 



IHAVE < identificador > 



En cada artfculo, el servidor receptor enviara en la respuesta un co- 
digo 335 si quiere recibir una copia del mismo o 435 si no le intere- 
sa. Si es preciso pasar el artfculo, se hace por medio del comando 
POST, y el servidor receptor enviara en la respuesta un codigo 235 
o, en caso de error, uno 436. Asimismo, puede suceder que al re- 
ceptor no le interese el artfculo despues de examinar su contenido; 
en este caso, la respuesta sera 437. 
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1 3) Conexion desde un servidor esclavo (SLAVE) 



Este comando sirve para informar al servidor de que la conexion pro- 
viene de un servidor esclavo. El servidor puede decidir, por ejemplo, 
dar mas prioridad a esta conexion que a las que provienen directa- 
mente de clientes porque se supone que atiende a mas usuarios. El 
codigo de respuesta es el 202. 



SLAVE 



14) Mensaje de ayuda (HELP) 

Este comando se utiliza para obtener un mensaje de ayuda. El servi- 
dor responde con un codigo 1 00 y, a continuacion, un texto informa- 
tivo de los comandos que acepta, acabado con una linea con un 
cardcter 



HELP 



15) Cerrar la conexion (QUIT) 

Este comando se utiliza para cerrar la conexion. El servidor responde 
enviando un codigo 205 y cerrando la conexion. 



QUIT 



La especificacion RFC 977 permite que las implementaciones ana- 
dan otros comandos a los estandares; sin embargo, recomienda que 
el nombre de estos nuevos comandos empiece con X para evitar po- 
sibles conflictos con posteriores extensiones oficiales. 

Algunos ejemplos de comandos implementados por muchos servido- 
res son los siguientes: 

• XGTITLE: confiere un tftulo descriptivo de uno o mas grupos. 



XHDR y XOVER: dan, respectivamente, el valor de un campo y un 
resumen de la cabecera de uno o mas artfculos. 
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XPAT: proporciona los valores de un campo de la cabecera que 
concuerdan con un patron, junto con los numeros de los artfculos 
correspondientes. 



La tabla siguiente resume los codigos de respuesta del protocolo NNTP: 



Tabla 15. 



Codigos de respuesta 






100 


Mensaje de ayuda. 


200 


Servidor preparado; se permite enviar artlculos. 


201 


Servidor preparado; no se permite enviar artfculos. 


202 


Conexion desde servidor esclavo. 


205 


El servidor cierra la conexion. 


21 1 


Grupo seleccionado. 


215 


Lista de grupos. 


220 


Contenido del artfculo. 


221 


Cabecera del artfculo. 


222 


Cuerpo del artfculo. 


223 


Identificador del artfculo. 


230 


Lista de artfculos nuevos. 


231 


Lista de grupos nuevos. 


235 


Artfculo recibido. 


240 


Artfculo enviado. 


335 


Preparado para recibir un artfculo de otro servidor. 


340 


Preparado para recibir un artfculo del cliente. 


400 


Servicio no disponible. 


41 1 


No existe el grupo. 


412 


No hay ningun grupo seleccionado. 


420 


No hay ningun artfculo seleccionado. 


421 


No hay artfculo siguiente. 


422 


No hay artfculo anterior. 


423 


No hay ningun artfculo con este numero. 


430 


No hay ningun artfculo con este identificador. 


435 


No se desea recibir el artfculo. 


436 


Error en la recepcion del artfculo. 
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Codigos de respuesta 







437 


Artfculo rechazado. 


440 


No se permite enviar artfculo. 


441 


No se ha podido enviar el artfculo. 


500 


Comando desconocido. 


501 


Error de sintaxis en el comando. 


502 


Permiso denegado. 


503 


Error interno. 



Actividad 

Estableced una conexion con un servidor NNTP (por 
ejemplo, con telnet servidor 119). Efectuad al- 
gunas operaciones como listar los grupos que haya 
(iatencion: en algunos servidores la lista puede tener 
mas de 10.000 Ifneasl), entrar en un grupo, ver la ca- 
becera de algun artfculo, leer alguno entero, etc., y ob- 
servad los codigos numericos de respuesta que envfa el 
servidor. 
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21. Servicio hipermedia: WWW 



21.1. Documentos hipermedia 

El servicio WWW ( world wide web ) ofrece acceso a informacion mul- 
timedia, que puede incluir contenidos de diferentes tipos (texto, image- 
ries, audio, video, etc.) y referencias a otros elementos de informacion, 
segun el modelo de los sistemas hipertexto. 



Un sistema hipertexto permite recorrer un documento de manera no 
necesariamente lineal o secuencial, sino siguiendo las referencias o 
enlaces que el usuario selecciona y saltando a la parte referenciada. 
Es decir, en lugar de seguir un unico camino lineal, se puede realizar 
un recorrido por el documento pasando por los arcos de un grafo. 
Esta manera de acceder a la informacion se suele llamar familiar- 
mente navegar. 



Cuando se generaliza la funcionalidad hipertextual 
para que permita navegar por elementos de informa- 
cion multimedia y no solo por texto, se suele hablar de 
sistemas hipermedia. 



En la terminologia WWW, cada uno de los elementos de informacion 
a los que se puede acceder se llama recurso. Los documentos hiper- 
media constituyen un caso particular de recurso que contiene infor- 
macion estructurada, posiblemente con diferentes tipos de contenido 
y enlaces a otros recursos. 

En la estructura de un documento, en general, se pueden distinguir 
los elementos siguientes: 

1) La estructura logica, es decir, la division del contenido en partes 
que se encuentran en diferentes niveles, como capitulos, seccio- 
nes, apartados, subapartados, titulos, parrafos, figuras, tablas, 
encabezamientos, notas, etc. 
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2) La estructura fi'sica, es decir, la disposicion de las partes del docu- 
mento en el medio de presentacion (por norma general, papel o 
pantalla): la division del documento en paginas y grupos de paginas, 
la distribucion del area de cada pagina en zonas para cabeceras y 
pies, los margenes, los espacios reservados a figuras, tablas, etc. 



En el modelo general de procesado de los documentos estructura- 
dos, el autor crea la estructura logica, con el contenido correspon- 
diente, y puede incluir ciertas directrices para controlar el aspecto 
visual que debera tener el documento. En numerosas ocasiones, a un 
determinado conjunto de directrices de este tipo se le da el nombre 
de estilo. A partir de esta informacion, un proceso denominado de 
formateo se encarga de generar la estructura ffsica. 



Existen diferentes representaciones normalizadas de los documen- 
tos estructurados, las cuales van destinadas a objetivos diferentes: 



Nota 



SPDL esta basado en otro 
lenguaje muy popular que 
sirve para representor docu- 
mentos formateados: 

el lenguaje PostScript. 



a) Representaciones quese centran en la especificacion de la es- 
tructura logica, como el SGML ( Standard Generalized Markup 
Language, publicado en el estandar internacional ISO 8879). 

b) Representaciones que se centran en la especificacion de la estruc- 
tura ffsica, como el SPDL ( Standard Page Description Language, 
publicado en el estandar ISO/I EC 1 01 80). 

c) Representaciones que comprenden tanto la estructura logica 
como la ffsica, por ejemplo el estandar ODA (Open Document 
Architecture, publicado en el estandar ISO/I EC 861 3 y en la serie 
de recomendaciones ITU-T T.410). 



21 .2. Marcado: el SGML 



Nota 



DSSSL es la sigla de docu- 
ment style semantics and 
specification language, pu- 
blicado en el estandar ISO/ 
IEC 10179 



El SGML contiene la especificacion de un lenguaje que solo permite 
representor la estructura de un documento desde el punto de vista 16- 
gico. En principio, un usuario puede aplicar los estilos que quiera 
para visualizar el documento. Sin embargo, lo mas habitual es que 
las aplicaciones que utilizan este lenguaje proporcionen una serie de 
reglas para interpretar la estructura del documento y, en particular, 
para formatearlo. Por otro lado, se ha publicado otro estandar, I la- 
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mado DSSSL, que permite definir estilos de presentacion con las 
transformaciones necesarias para convertir un documento SGML en 
otra notacion, como el SPDL. 

Un ejemplo de aplicacion basada en SGML es el HTML (Hypertext 
Markup Language ) disenado para especificar documentos hipermedia. 



Nota 

Actualmente, la especificacion oficial del HTML esta 
bajo el control de un grupo de empresas y organizacio- 
nes conocido como World Wide Web Consortium 
(W3C). Con anterioridad, la responsabilidad era de un 
grupo de trabajo de la Internet Engineering Task Force 
(IETF), que ceso sus actividades en 1 996 tras publicar el 
documento RFC 1866 con la especificacion HTML 2.0. 



El SGML se publico en 1 986 con el objetivo de facilitar la especifica- 
cion de documentos estructurados. El lenguaje definido en este es- 
tandar, sin embargo, es lo suficientemente general para permitir la 
representacion de muchos otros tipos de informacion estructurada 
(bases de datos, etc.). 



21.3. Transference de hipermedia: el HTTP 



Lectura complementaria 



Podeis ampliar la informa- 
cion sobre el SGML en la 
obra siguiente: 

Charles Goldfarb (1 990). 

The SGML Handbook. 
Oxford: Oxford University 
Press. 



El HTTP (hipertext transfer protocol) es la base del servicio WWW. Sus 
orfgenes fueron los trabajos de un grupo de investigadores del CERN 
(Centro Europeo de Investigacion Nuclear) que, al final de los anos 
ochenta y principios de los noventa, definieron un protocolo para ac- 
ceder de manera sencilla y comoda a la informacion distribuida en 
las diferentes sedes del centro. Cuando el conjunto de sistemas ac- 
cesibles con este mecanismo se extendio a otras organizaciones y 
pafses de todo el mundo, nacio lo que hoy conocemos como WWW 
(World Wide Web). 

De la misma manera que el HTML, el HTTPtambien evoluciona constan- 
temente a medida que los implementadores incorporan nuevas funcio- 
nalidades para adaptarlo a diferentes tipos de aplicaciones particulares. 
En 1 996, se publico el documento RFC 1 945, en que se define la version 
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HTTP/1 .0 (este documento tambien contiene las especificaciones de la 
denominada version 0.9 para facilitar la interoperabilidad con imple- 
mentaciones antiguas). Sin embargo, el ano siguiente ya se publico la es- 
pecificacion HTTP/1 .1 en el documento RFC 2068. 

A continuacion, veremos las caracterlsticas principales de la funciona- 
lidad que ofrece el HTTP. Sin embargo, antes de entrar en los detalles 
del protocolo, estudiaremos el metodo general utilizado en el servicio 
WWW para identificar la informacion a la que se quiere acceder. 



21.3.1. Direccionamiento: identificadores uniformes 
de recurso (URI) 



Nota 



La definicion de URI constituye 
otro ejemplo de especifica- 
cion en constante evolucion, 
al menos hasta que se pu- 
blico el documento RFC 
2396, en 1998. 



Desde un documento se pueden referenciar recursos especificando 
sus direcciones, que se representan por medio de lo que en la termi- 
nologfa WWW se denomina identificador uniforme de recurso o URI. 



La forma general de un URI se puede expresar del modo siguiente: 



esquema: identificador 



Esta es la forma correspondiente a un URI absoluto. La palabra que 
se encuentra antes del separador es el esquema, que determina 
la sintaxis del identificador. Esta sintaxis tambien puede permitir la 
especificacion de URI relativos, en que se omite el esquema y el se- 
parador " : ". 



Un URI puede ser un localizador (URL), si especifica como se accede 
al recurso, y/o un nombre (URN) si identifica el recurso por medio 
de un conjunto de atributos: 



ftp : / / [usuario [ : contrasena ] @ ] servidor/ camino 



Segun el esquema, estas son algunas sintaxis posibles de los URL: 

a) ftp 

Este tipo de URL identifica un recurso accesible por medio del 
protocolo FTP: servidor es el nombre del ordenador servidor 

302 




y camino es el nombre completo de un fichero o directorio. Si el 
nombre de usuario no se encuentra presente, significa que es pre- 
ciso utilizar anonymous y, como contrasena, cualquier cadena de 
caracteres. 

b) news 

Este URL identifica un conjunto de artfculos si identificador es el 
nombre de un grupo de noticias Usenet, en el caso de que solo sea 
un identificador de mensaje (campo Message-ID), entonces solo 
identificara un determinado artfculo: 



news : identificador 



c) mail to 

Este identificador URL representa una direccion de correo electronico: 



mailto: direccion 



d) telnet 

Este URL representa un servicio accesible por medio del protocolo Te- 
lnet en el servidor y el puerto especificados: 



telnet : / / [usuario [ : contrasena] @ ] servidor [ : puerto] [ / ] 



e) http 

Cuando deba accederse al recurso identificado por medio del HTTP, 
se utilizara un URL de acuerdo con la sintaxis siguiente: 



URL-HTTP = URL-HTTP-absoluto \ URL-HTTP-relativo 
URL-HTTP-absoluto = http :// servidor [: puerto] 

[ camino-absoluto ] 

URL-HTTP-relativo = camino -absoluto \ camino-relativo 
camino-absoluto = /camino -relativo 

camino-relativo = [camino] * ( /parametro) [? consulta ] 
[# fragmento ] 

camino = segmento * (/ segmento) 
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En esta sintaxis, servidor es el nombre del ordenador con que 
es preciso establecer la conexion HTTP para acceder al recurso, y 
Puerto es el numero de puerto en que debe efectuarse la co- 
nexion que, por defecto, es el numero asignado al servicio WWW, 
es decir, el 80. 



Nota 






segmento, 


parametro, 




consulta o 


fragmento 




pueden ser 


una cadena 




vacia. 





Cada uno de los segmentos que forman el camino se asocia, por 
norma general, a un nombre de directorio o de fichero. Estos nom- 
bres no pueden incluir los caracteres "/", " "?", "\", "#", """, "<", 

">" o espacio. El caracter "/" si que puede estar presente en un pa- 
rametro, y tanto "/" como " y "?" tambien pueden estar presentes 
en los componentes consulta y fragmento. 



Si en el camino aparece el caracter "%", debe ir seguido de dos di- 
gitos hexadecimales, y esta secuencia de tres caracteres equivale al 
caracter que tenga el codigo indicado por los digitos. Por tanto, se 
puede utilizar una secuencia "%HH" para representor cualquiera de 
los caracteres no permitidos en un URL, incluyendo el mismo caracter 
"%" (que se representarfa con "%25"). 



Nota 

A continuacion, presentamos diferentes ejemplos de URL 
con esquemas diferentes (lo dos ultimos son URL HTTP 
relativos): 

ftp: / /ftp. uoc.es/pub/doc/README 
news : comp . infosystems . www.misc 
mailto : Ernest . Udiant@ campus . uoc.edu 
http: //www. uoc.es/ 
http : / /www . acme . com/%7Eadmin/ 

http : / /www. acme . com/bus cador /bus ca . cgi?nom=Internet 
http : / /www. acme . com/ doc/ayuda .html#buscador 
/doc/ ayuda . html#buscador 
ayuda . html#buscador 



Los URL relativos se pueden utilizar en documentos HTML, en concre- 
to en los atributos que representan direcciones de otros recursos 
(HREF, SRC, ACTION). Estos URL se consideran relativos a una deter- 
minada direccion base, que es la indicada por el elemento BASE del 
documento o, si este elemento no se encuentra presente, la direccion 
que se ha utilizado para acceder al mismo documento HTML. 
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Para obtener el correspondiente URL absoluto, es preciso aplicar las 
reglas siguientes: 



1 ) Si el URL relativo contiene un camino absoluto, sustituye al camino 
de la direccion base. 

2) Si el URL relativo contiene un camino relativo (y el camino no esta va- 
cfo), se sustituye el ultimo segmento de la direccion base (la parte del 
camino que se encuentre despues del ultimo "/") por este. Como 
caso especial, cada segmento con nombre " . . " que se encuentre en 
el inicio del camino relativo debe suprimirse junto con el ultimo seg- 
mento que quede al final del camino de la direccion base. 

3) Si el camino del URL relativo esta vacio, pero hay alguno de los 
otros componentes (parametros, consulta, fragmento), se toma el 
camino de la direccion base y se sustituyen los componentes co- 
rrespondientes por los del mismo. 



Nota 

Interpretacion del URL relativo 

Dada la direccion base http :/ /www . uoc . edu/extern/ 
ct/home/home . html, los URL relativos siguientes debe- 
rian interpretarse de este modo: 



Nota 



Si el URL relativo esta com- 
pletamente vacio, se toma 
directamente toda la direc- 
cion base, incluyendo el 
fragmento, si hay (en los 
otros casos, el fragmento de 
la direccion base no se con- 
sidera). 



Tabla 16. 




URL relativo 


URL absoluto 


/accesset98/ 


http://www.uoc.edu/accesset98/ 


otras/pag ina.html 


http://www.uoc.edu/extern/ct/home/otras/pagina.html 


../../logo.ipeg 


http://www.uoc.edu/extern/logo.jpeg 


#final 


http://www.uoc.edU/extern/ct/home/home.html#final 



21.3.2. Conceptos basicos del HTTP 

El HTTP sigue el modelo general de peticiones y respuestas entre un 
cliente y un servidor. Se basa en un servicio de transporte fiable; pero, 
es independiente del mecanismo de transporte concreto utilizado. No 
obstante, lo mas habitual es que cliente y servidor se comuniquen por 
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medio del TCP. En este caso, el puerto por defecto para establecer las 
conexiones es el asignado oficialmente al servicio WWW, es decir, el 80. 

En el HTTP/1 .0, el cliente establece una conexion con el servidor y le 
envfa un mensaje HTTP con la peticion; y, a continuacion, el servidor 
envfa al cliente otro mensaje HTTP con la respuesta y cierra la co- 
nexion. Si quiere efectuar mas peticiones, el cliente debe establecer 
una nueva conexion para cada una. En el HTTP/1.1, en cambio, es 
posible intercambiar diferentes peticiones y respuestas en una misma 
conexion que se denomina conexion persistente. Este es el modo de 
funcionamiento por defecto en el HTTP/1.1. 

Un mensaje HTTP consta de una primera Ifnea, en la que hay infor- 
macion espedfica del protocolo, seguida de un mensaje con el mis- 
mo formato que los mensajes de correo electronico, segun la 
especificacion RFC 822. Es decir, despues de la primera Ifnea debe 
haber una cabecera formada por una serie de campos, una Ifnea en 
bianco y un cuerpo. En casos particulares, la cabecera y/o el cuerpo 
pueden estar vacfos, pero la Ifnea en bianco que los separa siempre 
debe estar presente. 

El cuerpo del mensaje, junto con los campos de la cabecera que pro- 
porcionan informacion sobre su contenido, forman lo que en el HTTP 
se denomina una entidad. Cada entidad corresponde a un recurso. 

Dependiendo de si el mensaje HTTP es una peticion o una respuesta, 
la primera Ifnea recibe el nombre de linea de peticion o linea de es- 
tatus, respectivamente. 

La sintaxis de una Ifnea de peticion es la siguiente: 

metodo <SP> URI <SP> version <CRLF> 

En esta Ifnea, metodo especifica que tipo de operacion (o, en la ter- 
minologfa HTTP, que metodo) solicita el cliente, URI identifica el re- 
curso a que se debe aplicar la operacion y version debe ser la 
cadena HTTP/1 . 0 o HTTP/1 . 1, segun la version del protocolo. El 
URI debe ser un URL HTTP relativo que contenga un camino absolu- 
to; es decir, que empiece por "/" (excepto cuando el servidor sea un 
proxy, como veremos mas adelante). 
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Nota 



Siempre que un usuario quiera utilizar un cliente 
para obtener el recurso dado por la direccion 
http : / / www . acme . com: 8000 / do c/principal. html, 
el cliente debe conectarse al puerto 8000 del servi- 
dor www.acme.com y enviarle una peticion que em- 
piece con esta linea: 

GET /doc/principal .html HTTP/1.0 

En este caso, el metodo utilizado es GET (obtener re- 
curso). Ahora bien, si la direccion fuera http:// 
www. acme . com: 8000/, la linea que deberia enviar- 
se seria simplemente la siguiente: 

GET / HTTP/1.0 



La sintaxis de las lineas de estatus es la siguiente: 

version <SP> codigo <SP> frase <CRLF> 



La cadena version es igual que en la linea de peticion, el codigo 
es un numero de tres digitos, el primero de los cuales indica de que 
tipo de respuesta se trata, y frase es un texto explicativo en formato 
libre, inteligible para los usuarios humanos. 

Los posibles codigos de una respuesta HTTP/1 .0 son los siguientes: 



Table 17. 



Codigo 


Significado 


200 


Operacion efectuada. 


201 


Se ha creado un nuevo recurso. 


202 


Peticion aceptada. 


204 


La respuesta esta vacia. 


301 


El recurso solicitado ha cambiado de direccion. 


302 


El recurso solicitado ha cambiado temporalmente de direccion. 


304 


El contenido del recurso no ha cambiado. 


400 


Peticion incorrecta. 


401 


Usuario no autorizado. 



Nota 



En el HTTP, el signiticado 
del primer digito del codigo 
de respuesta varia un poco 
de lo que se considera co- 
mun (que encontrareis en el 
anexo 4) y es el siguiente: 

• 1 : Informacion. 

• 2: Exito. 

• 3: Redireccionamiento. 

• 4: Error en el cliente. 

• 5: Error en el servidor. 
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Codigo 



Significado 



403 


Acceso prohibido. 


404 


No se ha encontrado el recurso. 


500 


Error interno del servidor. 


501 


Operacion no implementada. 


502 


Error en otro servidor. 


503 


Servicio no disponible en la actualidad. 



Nota 

En el HTTP/1.1 se han anadido a esta lista hasta 22 
nuevos codigos de respuesta. No obstante, si un clien- 
te recibe un codigo xyzque no conoce, debe interpre- 
tarlo como si fuera xOO. En este sentido, el codigo 1 00 
significa 'continuar' y el codigo 300 quiere decir 're- 
curso accesible en una direccion o mas'. 



Almacenamiento local de respuestas (memoria cache) 

Para optimizar el trafico de la red, es habitual que los clientes HTTP 
guarden una copia de las respuestas que reciben de los servidores, junto 
con el URL que han utilizado en la peticion. El almacen destinado a este 
fin recibe el nombre dememoria cache. Si el usuario quiere volver a ac- 
ceder a un recurso que ya habia solicitado previamente, el cliente puede 
utilizar la copia de la memoria cache en lugar de volver a enviar la mis- 
ma peticion al servidor. 

El cliente puede decidir, o el usuario puede configurar, el tiempo que 
se guardaran los elementos de la memoria cache, su dimension 
maxima o la politico que debera seguirse para borrar sus elementos 
cuando este llena. Asimismo, el HTTP tambien proporciona directri- 
ces para determinar que recursos se pueden guardar en la memoria 
cache y cuales no, o cuanto tiempo se puede guardar como maximo 
un determinado recurso. 

Nota 



Consultad los servidores in- 
termediaries en el apartado 
21 .3.4 de esta unidad. 
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Sin embargo, no solo los clientes pueden guardar copias de las res- 
puestas obtenidas de los servidores; tambien pueden hacerlo los ser- 
vidores intermediaries o proxies. 





Cabeceras de los mensajes HTTP 



Los compos que puede haber en la cabecera de un mensaje HTTP se 
pueden clasificar en cuatro grupos: 



1 ) Campos generales que pueden estar presentes tanto en los men- 
sajes de peticion, como en los de respuesta. 

2) Campos referentes a la entidad contenida en el cuerpo del men- 
saje y que tambien pueden estar presentes en peticiones y res- 
puestas. 

3) Campos propios de las peticiones. 

4) Campos propios de las respuestas. 

El HTTP proporciona un mecanismo de extension que permite incluir 
campos no estandar en las cabeceras. Si una implementacion no re- 
conoce un determinado campo, lo que debe hacer es simplemente 
ignorarlo (o retransmitirlo tal como lo encuentra si es un servidor in- 
termediario). 

Los campos que puede contener la cabecera son los siguientes: 

1 ) Campos generales definidos en HTTP/1 .0: 

a) Date : fecha. Indica la fecha y la hora en que se origino el men- 
saje. Los valores de los campos HTTP que representan fechas se 
deben expresar de una de estas tres maneras, siempre referidas 
al tiempo universal (TU, anteriormente conocido como hora del 
meridiano de Greenwich o GMT): 

Fri , 06 Dec 2002 09:22:15 GMT (RFC 1123, forma recomendada) 
Friday, 06-Dec-2002 09:22:15 GMT (RFC 850) 

Fri Dec 6 09:22:15 2002 (formato ANSI C) 

b) Pragma: lftdlrectrlz. Este campo sirve para proporcionar 
una lista de directrices a los sistemas que intervienen en la trans- 
ference (clientes o servidores). La semantica de las directrices 
depende de las implementaciones; sin embargo, hay una defi- 
nida por el protocolo, que se representa con la palabra no-ca- 
che. Si un mensaje de peticion contiene esta directriz, significa 
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que debe enviarse la peticion al servidor correspondiente aun- 
que exista una copia de la respuesta guardada en la memoria 
cache. 



Nota 

La especificacion HTTP/1.1 anade cinco nuevos com- 
pos generales: 

• Cache-Control: directrices sobre la politico de 
memoria cache. 

• Connection: opciones de conexion. La opcion 
close indica que el emisor cerrara la conexion 
despues de que se haya enviado la respuesta. 

• Transfer-Encoding: codificacion aplicada al 
cuerpo del mensaje. 

• Upgrade: versiones del protocolo soportadas. 

• Via: intermediaries por los que ha pasado el men- 
saje. 



2) Campos referentes a la entidad definidos en el HTTP/1 .0: 

a) Content- Length : l*digito. Indica la longitud en bytes del 
cuerpo de la entidad. Si este campo no esta presente en una res- 
puesta, el cliente solo puede saber cual es el final del cuerpo 
cuando el servidor cierra la conexion. En un mensaje de peticion 
que incluya un cuerpo, el campo Content-Length es obligato- 
rio, puesto que de otro modo el servidor no podrla enviar la res- 
puesta y no se podrla cerrar la conexion. 



Nota 



Consultad los nuevos com- 
pos de cabeceras en el 
subapartado 1 9.5.1 . 



b) Content-Type: tlpo. Indica el tipo de contenido del cuerpo de 
la entidad (por ejemplo, text/html si es un documento HTML). 
El valor de este campo se representa segun la especificacion MIME 
y, por tanto, puede incluir parametros (por ejemplo, char- 
set=ISO-8859-l si los caracteres estan codificados segun el al- 
fabeto latfnl). Todos los mensajes HTTP con cuerpo deberlan 
incluir el campo Content-Type. 
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c) Content-Encoding: codlficacion. Indica si se ha aplicado 
alguna transformacion al contenido de la entidad (por ejemplo: 
x-gzip). El valor de este campo se representa segun la especifi- 
cacion MIME. 

d) Last-Modified: fecha. Indica la fecha y la hora en que el re- 
curso contenido en el cuerpo se modified por ultima vez. 

e) Expires : fecha. Indica la fecha y la hora a partir de la cual 
el contenido del cuerpo se puede considerar obsoleto o cadu- 
cado al efecto de su almacenamiento en la memoria cache. La 
presencia de este campo significa que, posiblemente, el recur- 
so se modificara en la fecha indicada o dejara de existir; sin 
embargo, no implica que los cambios, si se producen, deban 
efectuarse necesariamente en esta fecha. Ahora bien, si la fe- 
cha de caducidad es igual o anterior a la especificada en el 
campo Date, la entidad no debe almacenarse en la memoria 
cache. 

f) Allow: lftmetodo. Indica los metodos HTTP que se pueden 
aplicar al recurso solicitado. 



Nota 

La especificacion HTTP/1 .1 anade seis nuevos campos 

de entidad adicionales: 

• Content-Base: direccion base para interpretar 
URL relativos. 

• Content-Language: lenguaje que se ha utilizado. 

• Content-Location: URI de la entidad, en caso 
de que el recurso correspondiente disponga de 
mas de una. 

• Content-MD5: secuencia de bits para comprobar 
la integridad del contenido. 

• Content-Range: por si una entidad se envia en 
diferentes fragmentos. 

• ETag: etiqueta asociada a la entidad, por si el re- 
curso dispone de mas de una. 



Ejemplo 



Ejemplos de listas de pro- 
ductos: 

• Lynx/2 . 8rel . 2 
libwww-FM/2 .14. 

• NCSA_Mosaic/2 . 6 
(Xll; SunOS 4.1.4 
sun4m) libwww/2.12. 

• Harvest/1.5.17. 



Nota 



Consultad la codificacion 
en Base64 en el apartado 
19.5.1. 



3) Campos propios de las peticiones HTTP/1 .0: 

a) From: direccion . Este campo contiene la direccion de co- 
rreo electronico del usuario que solicita el recurso. 

b) User-Agent: l*implementaci6n. Este campo permite 
identificar la implementacion del cliente. Se expresa como una 
lista de "productos" (por ejemplo, tipo de navegador, librerias 
de soporte que utiliza, etc.) con numeros de version opcionales 
(separados de los nombres con que puede incluir comen- 
tarios entre parentesis. El servidor puede utilizar esta informa- 
cion para generar estadfsticas, detector que implementaciones 
producen ciertos errores, adaptor las respuestas al tipo de 
cliente, etc. 

c) Referer: URI. Si el usuario selecciona un enlace de un do- 
cumento HTML o de otro recurso que tiene direccion propia, el 
cliente puede incluirla en el campo Referer del mensaje de 
peticion. El servidor puede utilizar esta informacion para gene- 
rar estadfsticas, detector desde que recurso se referencia una 
direccion incorrecta u obsoleta, etc. 

d) If-Modif ied-Since : fecha. Cuando el cliente ya dispone 
de una copia del recurso solicitado en la memoria cache, pue- 
de utilizar este campo para llevar a cabo una operacion GET 
condicional: si el recurso se ha modificado con posterioridad a 
la fecha indicada, se efectuara la operacion de manera normal 
y, si no, el servidor enviara una respuesta sin cuerpo y con el 
codigo 304. Este campo solo es aplicable al metodo GET. 

e) Authorization: esquemaftparametro. Con este campo, 
un usuario puede presentar sus credenciales a un servidor (por 
norma general, un nombre y una contrasena) para que le per- 
mita acceder a recursos no publicos, es decir, de acceso res- 
tringido. La primera parte de la credencial indica el esquema 
de autenticacion a utilizar. El HTTP/1 .0 solo define un esquema 
denominado basico, pero se puede utilizar cualquiera mientras 
sea conocido por el cliente y el servidor. Si se utiliza el esquema 
basico, el valor de este campo debe ser la palabra Basic se- 
guida de la cadena de caracteres que resulta de codificar en 
Base64 el nombre de usuario y su contrasena separados por " : ". 
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Ejemplo 

Si el nombre de usuario es webmaster y su contra- 
sena es Secret, se codificara en Base64 la cadena 
webmaster : Secret . El campo quedarfa de este 
modo: 

Authorization : Basic d2VibWFzdGVy01NlY3 JldA== 

Obviamente, la descodificacion de este campo es trivial 
y, por tanto, no hay proteccion contra terceros que ten- 
gan la posibilidad de inspeccionar los mensajes y de- 
seen obtener un acceso no autorizado. Para conseguir 
que el metodo de autenticacion sea mas seguro, se 
puede utilizar un esquema mas sofisticado o alguna 
variante del protocolo basada en el cifrado de los da- 
tos, por ejemplo el HTTPS. 



La respuesta a una peticion que incluya el campo Authorization 
no deberia guardarse en la memoria cache. 



Nota 

En la especificacion HTTP/1.1 se anaden los campos 

de peticion siguientes: 

• Accept: tipo de contenido que el cliente puede 
aceptar. 

• Accept-Charset. 

• Accept-Encoding. 

• Accept-Language. 

• Host: nombre del servidor a quien va dirigida la 
peticion, por si tiene mas de uno; este campo, 
obligatorio en las peticiones HTTP/1.1, permite 
que un ordenador con diferentes nombres actue 
como si fuera diferentes servidores al mismo 
tiempo. 
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• If-Match: permite comparar entidades por sus 
etiquetas. 

• I f-None-Match. 

• If-Range. 

• If-Unmodified-Since. 

• Max-Forwards. 

• Proxy-Authorization. 

• Range: sirve para solicitor un fragmento de una 
entidad. 

4) Campos propios de las respuestas HTTP/1 .0: 

a) Server: l*implementacion. Este campo es similar a User- 
Agent, pero referido al servidor. 

b) Location: URI. Indica que el recurso solicitado debe obtenerse 
en otra direccion. Este sera el caso cuando el codigo de respuesta 
sea 301 6 302. Por norma general, cuando el cliente reciba una 
respuesta que incluya este campo, generara de manera automa- 
tica una nueva peticion con la direccion indicada. 

c) WWW-Authenticate : l#(esquema realm = " reino" *( , 
parametro ) ) . Este campo es obligatorio cuando el codigo de 
las respuestas es 401 . Indica que es necesario presentar una cre- 
dencial para acceder al recurso solicitado, o que la que se ha pre- 
sentado no es valida. 

Un servidor puede agrupar sus recursos de acceso restringido en 
reinos, cada uno con su esquema de autenticacion y conjunto de 
usuarios autorizados (con una misma credencial deberia poderse 
acceder a todos los recursos de un reino). El valor de este campo 
es una lista con los nombres de los reinos aplicables al recurso soli- 
citado, junto con sus esquemas y parametros opcionales para poder 
llevar a cabo la autenticacion con el campo Authorization de la 
peticion. 
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Nota 



En la especificacion HTTP/1.1 se anaden los campos 

de respuesta siguientes: 

• Age. 

• Proxy-Authenticate. 

• Public: lista de metodos soportados por el ser- 
vidor. 

• Retry-After. 

• Vary: lista de campos de la peticion que se han 
utilizado para seleccionar una entidad, cuando el 
recurso dispone de mas de una. 

• Warning: informacion adicional sobre el estatus 
de la respuesta. 



21.3.3. Metodos del servicio HTTP 



El protocolo HTTP/1 .0 define los tres metodos siguientes: 



1) Metodo GET. Este metodo sirve para obtener la entidad corres- 
pondiente al URI especificado en la Ifnea de peticion. Por norma 
general, el servidor traducira el camino del URI a un nombre de 
fichero o de programa: 

• En el primer caso, el cuerpo de la entidad sera el contenido del 
fichero. 

• En el segundo caso, el servidor ejecutara el programa y la en- 
tidad sera el resultado que genere. 



Nota 



Cuando el camino de un URI 
identifica un programa, la 
manera como se le pasan 
los valores de los parame- 
tros o las consultas es un 
asunto local del servidor. Por 
ejemplo, un mecanismo uti- 
lizado habitualmente es el 
denominado CGI (Common 
Gateway Interface). 



Los componentes parametro y/o consulta del URI se pueden 
utilizar como argumentos del programa. 



2) Metodo HEAD. Este metodo es igual que el GET, excepto que en 
la respuesta el cuerpo estara vacio y, portanto, solo tendra cabe- 
cera (que debera ser identica a la que se habria enviado si el me- 
todo fuera el GET). Por norma general, se utiliza el metodo HEAD, 
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por ejemplo, para comprobar si un URL es valido o para obtener 
informacion sobre un recurso sin necesidad de transferir su con- 
tenido. 



3) Metodo POST. Este metodo sirve para enviar una entidad que 
el servidor debe incorporar al recurso identificado por el URI 
de la Ifnea de peticion. La semantica de este metodo depende 
del tipo de recurso de que se trate. Por ejemplo, se puede uti - 
lizar para anadir contenido a un recurso existente, para enviar 
un mensaje a un tablon de anuncios o un grupo de noticias, 
para crear un nuevo registro en una base de datos, para pasar 
datos a un programa que debe ejecutarse en el servidor, etc. 
Un caso tfpico de este ultimo ejemplo son los datos de un for- 
mulario HTML. 



El codigo de respuesta a una operacion POST por norma general 
sera 201 , si como resultado, se ha creado un nuevo recurso (en este 
caso, el cuerpo de la respuesta deberfa contener una referencia a 
este recurso), o bien 200 6 204 si no se ha creado ninguno (el cuer- 
po de una respuesta 200 contendra una descripcion del resultado 
obtenido, y el de una respuesta 204 simplemente estara vado). 



Una propiedad del metodo POSTes que, si se envfan dos peticiones 
iguales, el resultado de la segunda no debe ser necesariamente el 
mismo que el de la primera. Portanto, la respuesta a una operacion 
POST no deberfa guardarse en la memoria cache. 



Not a 

En el HTTP/1 .1 se han anadido una serie de metodos 

nuevos, entre lo cuales, los siguientes: 

• PUT: para crear un recurso con el URI especificado 
en la peticion. 

• DELETE: para borrar un recurso. 

• OPTIONS: para obtener informacion sobre las op- 
ciones de transferencia. 

• TRACE: para obtener una copia del mensaje como 
ha llegado a su destino final. 
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Actividad 

Estableced una conexion con un servidor HTTP con telnet 
servidor 80 y averiguad la fecha en que ha sido 
modificada por ultima vez la pagina principal, o algu- 
na otra informacion referida al servidor (con un men- 
saje formado por la linea HEAD / HTTP/1.0, una 
cabecera vacia, una Ifnea en bianco y un cuerpo vacfo). 



21.3.4. Intermediarios: proxies y pasarelas 

El modelo general del HTTP no solo considera la conexion directa 
de un cliente con el servidor, sino tambien la conexion por medio 
de servidores intermediarios, como es el caso de los proxies: 



Figura 88. 



Conexidn directa 



GET /recurso HTTP/1.0- 



Servidor 



Conexion a troves de servidores intermediarios 



get http:// 

servidor/ 
recurso http/ 1.0" 



GET / 

.recurso http /1 . o Servidor 



En la configuracion con proxy, el cliente establece la conexion con 
el servidor proxy que, a su vez, establece otra conexion, como 
cliente, con el servidor final. Cuando el proxy recibe el mensaje de 
peticion del cliente, puede generar una respuesta propia o retrans- 
mitirla al servidor final. En el segundo caso, el proxy puede intro- 
duce modificaciones en la peticion, segun la aplicacion para la 
que este disenado, y, cuando reciba la respuesta del servidor final, 
la retransmitira al cliente, tambien con la posibilidad de efectuar 
cambios. 

Asimismo, es posible que haya mas de unproxy en la cadena; es de- 
cir, que el primer proxy no se conecte directamente al servidor final, 
sino por medio de otro proxy, y asi sucesivamente. 
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En las peticiones que un cliente (u otro proxy) envia a un proxy, existe 
una variacion respecto al caso de la conexion directa de cliente a ser- 
vidor: el URI de la linea de peticion no debe ser un URL HTTP relativo, 
sino que debe ser un URI absoluto. De lo contrario, el proxy no sabrfa 
cual es el servidor final al que va destinada la peticion. 

El uso de un servidor proxy tiene diferentes aplicaciones. Las princi- 
pales son las siguientes: 

a) Actuar como cortafuegos que aisle una red local del resto de las 
redes. En esta configuracion, los clientes no tienen acceso directo 
al exterior de su red, y toda comunicacion con los servidores re- 
motos tiene lugar por medio del proxy. Elio permite minimizar el 
riesgo de que usuarios externos comprometan la seguridad de los 
sistemas locales (accesos no autorizados, sabotajes, etc.). 

b) Tener una memoria cache compartida entre los usuarios de la red 
local. Si diferentes clientes solicitan directamente un mismo recurso, 
por norma general guardaran la misma copia de la respuesta en sus 
respectivas memorias cache. Si lo solicitan por medio de un proxy, la 
primera peticion necesitara un acceso al servidor remoto; sin embar- 
go, las siguientes quiza puedan aprovechar la copia ya guardada en 
la memoria cache, aunque provengan de clientes diferentes. 

c) Construir una jerarqufa de memorias cache d e proxies: en el nivel 
mas bajo se encuentran los proxies a que acceden directamente 
los clientes, en un segundo nivel existen los proxies a que acce- 
den los del primer nivel, etc. Incluso puede haberprox/esa escala de 
todo un pais. Hay un protocolo denominado ICP ( Internet cache 
protocol) que permite coordinar los diferentes servidores proxy de 
una jerarqufa. 

Nota 

Ademas de los proxies, existe otro tipo de servidor inter- 
mediario llamado pasarela. Las pasarelas actuan como 
si fueran el servidor final, con la diferencia respecto al 
proxy de que el cliente no sabe que no se conecta direc- 
tamente al servidor final. Una pasarela se puede utilizar 
como cortafuegos en la red del servidor o para traducir 
las peticiones HTTP de manera que se pueda acceder a 
recursos almacenados en sistemas no HTTP. 
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22. Mensajeria instantanea 



No cabe duda de que Internet ha cambiado la manera de comuni- 
carnos. Para muchos de nosotros, el correo electronico ha reempla- 
zado casi por completo al correo tradicional y ha hecho disminuir de 
forma considerable las llamadas telefonicas que realizamos. Diaria- 
mente se envian millones de correos electronicos. 



A pesar de lo rapido que es el sistema de correo, aun no lo es bastan- 
te. En algunos servidores, se pueden acumular retardos de algunos 
minutos. Ademas, por rapido que sea, se trata de un sistema asincro- 
no, que no permite mantener una conversacion fluida. Cada mensaje 
enviado o recibido implica una serie de pasos a seguir, botones a pul- 
sar y ventanas a abrir. Por todo el lo, se han popularizado los sistemas 
de mensajeria instantanea, un clasico del modelo peer-to-peer. 



Las aplicaciones de mensajeria instantanea permiten mantener una 
lista de personas (las buddy lists o listas de contactos) con las que uno 
desea mantenerse en contacto y mandarles mensajes, siempre y 
cuando esten concetados. Este detalle no nos debe preocupar, por- 
que es la propia aplicacion la que se encarga de verificarlo. 



La manera de mandar mensajes es muy simple. La aplicacion nos 
presenta una ventana en la que tecleamos el contenido del mensaje 
y donde se vera lo que nos conteste el interlocutor. De esta manera, 
se puede mantener una conversacion en tiempo real. 

Ademas de la conversacion basica, la mayoria de programas de men- 
sajeria instantanea ofrecen otras prestaciones, como las siguientes: 



Nota 



Algunos sistemas permiten 
el uso de camaras de video, 
microfonos y altavoces para 
que la conversacion no se 
circunscriba solo a texto es- 
crito. 



• Chat que permite establecer conversaciones en grupo. 

• Pizarra que permite ver dibujos realizados por el interlocutor, en 
el momento o grabados en archivos. 

• Archivos que permite compartir archivos. 
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Desde que en 1 983 aparecio el primer sistema de mensajeria instan- 
tanea, han salido al mercado otros muchos productos, algunos 
usando protocolos propietarios, otros intentando buscar un estan- 
dar. De hecho, la IETF ha recopilado muchas de estas contribuciones 
y esta desarrollando el Instant Messaging and Presence Protocol, por 
el cual se espera que pase el futuro de la mensajeria instantanea. 



Nota 

En general, el honor de haber creado el primer siste- 
ma de mensajena instantanea se atribuye a Mirabilis, 
la compama formada por cuatro estudiantes israelies 
que en 1 996 lanzo ICQ. Pero no debemos olvidar que 
en los sistemas Unix existe desde 1 983 una aplicacion lla- 
mada talk que permite la conversacion entre dos usua- 
rios conectados a sendos sistemas Unix via telnet o 
rlogin 

Seguramente, la proliferacion de los ordenadores 
domesticos, Internet y la web de finales de los noven- 
ta, mayoritariamente en entorno Windows, ha eclip- 
sado un tanto todo lo que tenia que ver con el 
entorno Unix. 



22.1 . Programas de mensajeria instantanea 



Sin pretender crear una lista exhaustiva, vamos a repasar los princi- 
pales programas que proporcionan la funcionalidad de la mensajeria 
instantanea en un entorno peer-to-peer. Algunos de los programas 
presentados son de software libre, pero otros no. 



22.1.1. ICQ 



Nota 



La direccion de la web 
de ICQ es la siguiente: 
http://www.icq.com. 



ICQ fue el primer programa que aparecio (en 1996) y actualmente 
aun es de los mas populares. Las siglas responden a la frase 7 seek 
you", ('te estoy buscando'). ICQ usa control centralizado a traves de 
servidores, y la comunicacion entre clientes y servidores, y entre clien- 
tes se realiza mediante un protocolo propietario (ICQ, v.5). 
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22.1.2. AIM 



AIM (AOL Instant Messenger), que aparecio poco despues de ICQ, 
es la evolucion de las comunidades que America OnLine ya tenia de- 
sarrolladas con otras tecnologias mas antiguas, como las BBS ( Bulle- 
tin Board System). AIM tambien usa un protocolo propietario. Por 
tanto, el cliente tiene que ser especifico para este entorno. 



Nota 

En 1998, AOL compro Mirabilis e integro ICQ en su 
suite de servicios ofrecidos. 

22.1.3. MSN Messenger 

Microsoft tambien ha entrado en el mundo de los sistemas de men- 
sajeria instantanea con MSN (Microsoft Network) Messenger. Es muy 
parecido a los dos descritos anteriormente. 

22.1.4. Jabber 

Jabber es mas que un mero sistema de mensajeria. Es un conjunto 
de protocolos y tecnologias que permiten el desarrollo de multiples 
aplicaciones peer-to-peer. Permite desarrollar clientes, servidores, 
componentes, bibliotecas, etc. Esta basado en XML y es la base de 
los protocolos que la IETF esta en proceso de estandarizacion. 

Sus autores presentan entre las ventajas de Jabber las siguientes: 
permite entornos descentralizados, es abierto, publico, seguro, ex- 
tensible y flexible. 

22.1.5. GAIM 

Gaim es un cliente de mensajeria instantanea multiprotocolo, para 

I Nota 

GNU/Linux, Unix BSD, MacOS X y Windows. Es compatible con AIM, 

ICQ, MSN Messenger, Yahoo, IRC, Jabber, Gadu-Gadu y Zephyr. 



La direccion de la web de 
GAIM es la siguiente: 
http://gaim.sourceforge.net. 



Nota 



La direccion de la web de 
Jabber es la siguiente: 
http://www.jabber.org. 



Nota 



La direccion de la web de 
MSN Messenger es la si- 
guiente: 

http://messenger.msn.com 



Nota 



La direccion de la web de 
AIM es la siguiente: 

http://www.aim.com. 



Una de sus mejores prestaciones es que permite estar conectado con 
diferentes redes de mensajeria simultaneamente. Asi, un usuario de 
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Gaim puede estar en un chat de AOL mientras esta conversando con 
un amigo de Yahoo y dentro de un canal IRC, todo en la misma apli- 
cacion. 
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Resumen 



En este curso hemos presentado las bases de funcionamiento de la 
red Internet. 

En la primera parte se han presentado los conceptos basicos de re- 
des de computadores y los diferentes sistemas de comunicaciones 
que se utilizan hoy dfa, siguiendo un hilo conductor historico, que 
permite entender el porque de muchas de las limitaciones y particu- 
laridades que poseen. Se ha expuesto, tambien, la arquitectura de 
protocolos, un concepto basico en redes de computadores. Como 
paradigma de dicho concepto, se ha explicado el modelo de referen- 
da OSI y se han descrito los siete niveles que lo forman. Las arqui- 
tecturas reales, en particular Internet, suelen describirse y explicarse 
en relacion con el modelo OSI. 

En la segunda parte hemos hecho un repaso, desde un punto de vista 
descriptivo, a las redes de area local. El principio basico de funcio- 
namiento de las redes de area local es la difusion de tramas en un 
medio compartido. Asi, las estaciones de la red, cuando quieran es- 
tablecer una comunicacion con otra (u otras) estaciones, deberan ge- 
nerar tramas de bytes a partir de los datos que quieran transferir. Y 
ponerlas en el medio para que lleguen a su o sus destinatarios. 

Se han presentado las topologfas mas usuales, destacando las topo- 
logfas en bus y en anillo. En un bus, todas las estaciones se conectan 
a un mismo cable, mientras que en un anillo, cada estacion esta co- 
nectada a dos mas, creando una estructura circular. Ambas topolo- 
gfas tienen ventajas e inconvenientes, siendo el mas importante de 
estos la dificultad de mantenimiento y localizacion de averfas que 
presentan ambas. Esto ha propiciado el desarrollo del cableado es- 
tructurado, como mecanismo para instalar redes de area local mas 
fiables y siguiendo estandares universales. 

Asociados al cableado estructurado han aparecido dispositivos muy 
comunes hoy en dfa como son los concentradores y los conmutado- 
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res. Los primeros simulan un bus y los segundos aprovechan el con- 
cepto de conmutacion para conseguir redes mas eficientes. Siempre 
que se puede, las tramas no se difunden a todas las estaciones pre- 
sentes en la red, si no solo a sus destinatarias. 

Finalmente se han presentado las politicos de acceso al medio mas 
habituales, las cuales van asociadas a la topologia usada. Asi, he- 
mos visto la politico de paso de testigo como la mas adecuada para 
las redes en anillo, y la CSMA/CD, que se usa en la mayorfa de las 
redes en bus, tanto si es un bus cableado como a traves de un con- 
centrador. 

En la tercera parte, se han descrito de los protocolos que se utilizan 
en la red Internet. En concreto, se han visto los protocolos del nivel 
de interconexion de red, que son IP y sus asociados ARP e ICMP, y los 
protocolos del nivel de transporte: TCP y UDP. 

Se ha visto el fenomeno del encapsulamiento de la informacion, 
como resultado de tener diferentes protocolos involucrados en una 
misma conexion, y como este encapsulamiento afecta al nivel de red. 

Uno de los aspectos mas relevantes del protocolo IP es la asignacion 
de direcciones. Hemos visto como cada interfaz conectada a Internet 
debe tener una direccion IP unica que la identifique. Las direcciones 
IP no solo identifican estaciones, sino tambien la red o subred donde 
esta la estacion. De este modo, es posible encaminar los paquetes IP 
a traves de diferentes encaminadores y, por lo tanto, a traves de di- 
ferentes redes. 

El protocolo ICMP nos permite resolver incidencias que puedan ocu- 
rrir en la Red. Hemos descrito las peculiaridades de este protocolo, 
asf como dos utilidades como son el ping y el traceroute, de uso 
muy habitual. 

Hemos descrito las redes de acceso a Internet mas habituales, 
como son la red Ethernet, el acceso mediante una conexion tele- 
fonica con el protocolo PPP y el acceso mediante el protocolo 
ADSL, que permite usar el cable telefonico pero sin tener que es- 
tablecer una llamada. 
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Por lo que respecta al nivel de transporte, hemos visto como su prin- 
cipal objetivo es entregar la informacion a los niveles orientados a la 
aplicacion en los extremos de la red. En la jerarquia de protocolos 
TCP/IP se definen dos protocolos de transporte: 

1 ) El UDP, que es un protocolo no orientado a la conexion. Portanto, 
no efectua ningun control de errores ni de flu jo. Si un datagrama 
UDP llega equivocado (el UDP utiliza un codigo detector de erro- 
res), el UDP lo descarta y no lo entrega a la aplicacion. Esta ultima 
debera ser capaz de responder a este tipo de servicio o debera 
asumir la perdida de la informacion. Este tipo de servicio puede 
ser util en aplicaciones en tiempo real, en las que es mas impor- 
tante que la informacion llegue cuando le toca; es decir, con un 
retardo limitado, que no que se pierda una parte de la misma. 

2) El TCP, que es un protocolo orientado a la conexion. Habra una 
fase de establecimiento de la conexion (el llamado procedimiento 
three-way handshake), una fase de transmision de la informacion 
y una fase de finalizacion de la conexion. El TCP entregara la in- 
formacion a la aplicacion totalmente libre de errores. Para conse- 
guirlo, necesita efectuar un control de errores y de flu jo. El TCP 
utiliza un codigo detector de errores junto con un protocolo de re- 
transmisiones para recuperar la informacion erronea. Como las 
memorias intermedias de recepcion se pueden desbordar, el TCP 
utiliza un control de flujo por ventana deslizante. El TCP debe 
dimensionar correctamente los temporizadores de retransmision. 

En la cuarta y ultima parte, se ha presentado el concepto de progra- 
macion distribuida y el modelo cliente/servidor, que es el mas utili- 
zado. Tambien se ha presentado el modelo peer-to-peer, que no es 
una alternative al anterior como a veces se ha planteado, porque no 
es un modelo de programacion de aplicaciones, sino que hace refe- 
renda al tipo de maquinas que se interconectan. 

Tambien se ha descrito el servicio de nombres de dominio, que pro- 
porciona acceso a una base de datos distribuida portoda la Red que 
permite obtener informacion sobre un determinado nombre. Las 
consultas mas habituales son para averiguar la direccion IP que co- 
rresponde a un nombre de servidor, pero tambien es posible obtener 
el nombre del servidor de correo de un dominio dado, el nombre de 
una maquina a partir de su direccion IP, etc. 
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Por lo que respecta a las propias aplicaciones, en esta unidad se han 
presentado los llamados servicios basicos de Internet, que son: 

• Telnet: protocolo general para establecer sesiones interactivas 
con un servidor que permite que el cliente actue como un terminal 
virtual. 

• rlogin: protocolo de terminal virtual con facilidades para simplifi- 
car el proceso de identificacion del usuario. 

• rsh, rexec: protocolos para la ejecucion remota de procesos en el 
servidor. 

Se han presentado tambien los protocolos mas usados quizas hoy en 
dfa, como son la transferencia de archivos, el correo electronico, el 
servicio de news, el WWW y la mensajena electronico, con sus mul- 
tiples posibilidades. 

Sobre el FTP, se ha comentado que permite copiar archivos del clien- 
te al servidor, del servidor al cliente y tambien de un servidor a otro, 
y que proporciona operaciones para que el cliente pueda manipular 
el sistema de archivos del servidor. 

Sobre el correo electronico, que es un servicio basado en los mismos 
conceptos del correo postal, se ha comentado en concreto la filosoffa 
de almacenamiento y reenvfo. 

La norma RFC 822 especifica el formato de los mensajes, y la norma 
MIME especifica un conjunto de extensiones para, por ejemplo, ad- 
juntar archivos y usar diversos idiomas. 

Tres protocolos proporcionan las diferentes funcionalidades necesa- 
rias: 

• SMTP: transferencia de mensajes. 

• POP3: acceso simple a buzones de correo. 

• IMAP4revl : acceso complejo a buzones de correo. 
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El servicio de noticias (news) facilita la publicacion de mensajes con 
un alcance que puede ir desde el ambito local de una organizacion, 
hasta el ambito mundial (toda la Internet). Se basa en la propaga- 
cion de los mensajes entre los diferentes servidores por medio del 
NNTP. Este mismo protocolo puede ser utilizado por los clientes para 
acceder a los mensajes guardados en un servidor o para enviar otros 
nuevos. 

El servicio WWW permite "navegar" por un conjunto de elementos 
de informacion interconectados con referencias o enlaces entre sf 
que pueden contener datos con diferentes tipos de representaciones 
(texto, imagenes, audio, video). El protocolo que proporciona el ac- 
ceso a esta informacion es el HTTP. 

El servicio de mensajerfa instantanea esta soportado por diferentes 
protocolos, algunos propietarios. Existen diferentes plataformas que 
lo proporcionan y tambien se han desarrollado diferentes clientes 
multi protocolo que permiten acceder a diferentes redes de mensaje- 
ria simultaneamente. 
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Anexos 



Anexo 1 



El algoritmo checksum 

Los protocolos IP y TCP utilizan, entre otros, un sencillo checksum para 
la deteccion de errores. Esta es una version del algoritmo checksum: 



u_short checksum (u_short * addr, int len) 

{ 

int aux_len = len; 
u_short *aux_addr = addr; 
u_short res; 
int sum = 0 ; 

while (aux_len > 1) 

{ 

sum+ = *aux_addr++; 
aux_len- = 2; 

} 



if (aux_len == 1) 

sum+ = * (u_char) *aux_addr; 

sum = (sum>>16) + (sum & Oxffff) ; 
sum+ = (sum>>16); 
res = ~sum; 

return res; 

} 
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Anexo 2 



Nota 



En los sistemas Unix podreis 
encontrar mas informacion 
utilizando el comando man. 
Por ejemplo, para saber mas 
detalles del comando route 
de Unix podeis ejecutar: 

$ man route 



Nota 



Para ejecutar los comandos 
que se muestran en este 
anexo se requiere tener pri- 
vilegios de superusuario. 



Aplicaciones mencionadas en el texto 

1) Aplicaciones estandar 

A continuation, resumimos las aplicaciones estandar que se han vis- 
to en el cursoy que estan disponibles en entornos Unix y GNU/Linux. 



• ping: por medio de paquetes ICMP (del tipo peticion de eco yres- 
puesta de eco) permite saber si una maquina esta funcionando o 
no y tener una idea de cual es el retardo de ida y vuelta ( round-trip ). 
Asimismo, permite saber por que maquinas pasa el paquete hasta 
que llega a destino. Para esta funcion, va mejor el programa tra- 
ceroute, a causa de las limitaciones inherentes a los paquetes 
ICMP. 

• traceroute: permite averiguar la ruta que se sigue desde el 
equipo local hasta un destino cualquiera de Internet. Marca los 
retardos existentes en cada uno de los nodos que es preciso cru- 
zar. Se basa en el campo TTL del paquete IP y los mensajes ICMP- 
time-to-live-exceeded. Esta aplicacion no esta disponible en algu- 
nas distribuciones de Unix y distribuciones de GNU/Linux, pero se 
puede conseguir facilmente. 

• arp: permite consultar y modificar la tabla ARP (cache ARP) de 
una maquina. 

• route: sirve para consultar y modificar la tabla de direcciona- 
miento IP de una maquina conectada a Internet. 

• ifconfig: permite consultar el estado de las tarjetas de red dis- 
ponibles en el sistema local. 

• netstat: proporciona estadfsticas de los protocolos TCP y UDP. 
Permite listar los puertos que se escuchan. Muestra el estado en 
que se encuentran los sockets TCP. Si quereis un listado de todos 
los sockets activos y puertos abiertos, haced netstat -a, y, si os 
interesan otras variantes, consultad la ayuda. 

• telnet: ofrece, aparte de la principal emulacion de terminal, co- 
nectar y experimentar los protocolos ASCII. 
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2) Aplicaciones no estandar 



• netcat (licencia GPL-Lenguage C): esta aplicacion nos permite 
utilizar conexiones TCP y UDP desde la Ifnea de comandos (por 
ejemplo, transmitir un fichero) o comprobar que puertos tiene 
abiertos una determinada maquina, entre otros servicios. 



• tcpdump [Unix (software libre-lenguaje C)]: permite analizar el tra- 
fico de la red por medio de conexion (LAN o punto a punto). Al con- 
trario de lo que su nombre indica, es capaz de interpretar los 
paquetes no solo en el ambito TCP, sino tambien en el IP, red, y 
aplicacion (para aplicaciones comunes). Es una herramienta im- 
prescindible para cualquier administrador de sistemas, aunque no 
aparezca en las distribuciones de las diferentes variantes de Unix. 
El codigo es de libre distribucion. Sus autores son Van Jacobson, 
Craig Leres y Steven McCanne, de la Universidad de California, 
aunque el programa en que se basaba el original, el Etherfind, era 
propiedad de Sun Microsystems y se distribufa dentro de SunOS. 



Nota 

En LAN, el tcpdump pone la tarjeta de red en modo 
promiscuo. Lo que significa que todo el trafico de la 
red es visible, con lo que cualquier usuario malinten- 
cionado (un hacker ) puede hacer un mal uso del mis- 
mo. Por tanto, el tcpdump y otras herramientas 
similares o derivadas del tcpdump, conocidas como 
detectores (sniffers ) se pueden considerar como una 
herramienta potencialmente peligrosa. De hecho, lo 
que es arriesgado es no utilizar al menos uno de los 
tres mecanismos de proteccion mas importantes con- 
tra los detectores: cifrado, cifrado y cifrado. 



A continuacion, se indican los resultados que puede mostrar el pro- 
grama tcpdump. 

3) El programa tcpdump 

El programa tcpdump permite capturar y filtrar paquetes que cruzan 
una interfaz de red que se ha activado en modo promiscuo (todos los 
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paquetes que pasan por el medio son capturados y filtrados). Los pa- 
quetes son procesados por un software especial que solo puede eje- 
cutar el superusuario (root) de la maquina. 



Para ver como funcionan los diferentes protocolos, proporcionamos 
ejemplos de las trazas que muestra el tcpdump durante el estable- 
cimiento o la terminacion de la conexion. 



Para ver como funciona este comando, puede utilizarse la instruccion 
man de Unix (o GNU/Linux). En este anexo ofrecemos un ejemplo del 
significado de la traza del tcpdump. 



El formato general de salida del tcpdump es el siguiente: 



Data src> dst: flag data-sqno ack window urgent options 



El significado de los componentes del formato son los siguientes: 

• data: este componente nos proporciona la hora en que se pro- 
dujo el acontecimiento en formato hora:minutos:segundos.micro- 
segundos (o milisegundos, segun la resolucion del reloj). 

• src y dst: son las direcciones IP y los puertos TCP/UDP de las 
conexiones de fuente y de destino. 

• flags: son una combinacion de los posibles indicadores de un 
segmento/datagrama TCP/UDP: S (SYN), F (FIN), P (PUSH), R 
(RST) y (que significa que no hay indicadores). 

• data-sqno: describe el numero de secuencia de la porcion de datos. 

• ack: es el numero de secuencia del byte siguiente que espera re- 
cibir el otro extremo TCP/UDP. 

• window: es el tamano de la ventana que el receptor advierte al 
transmisor. 

• urgent: indica que existen datos urgentes en este segmento/da- 
tagrama. 

• options: son las opciones TCP que suelen estar entre corchetes 
del tipo < >; por ejemplo, el tamano maximo del segmento (por 
ejemplo, <mss 1.024>). 
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Supongamos que hacemos un rlogin desde la maquina argos 
(fuente) hasta la maquina Helios (destino). Un ejemplo de una Ifnea 
que retorna el comando tcpdump serfa el siguiente: 

• 12:34:23.165439 argos. 1023 > helios . login: S 7838437: 

7838437 (0) win 4096 <mss 1024> 

• 12:34:23.165439 helios. login > argos. 1023: S 453534: 

453534 (0) ack7838438 win 4096 <mss 1024> 

La primera Ifnea indica lo siguiente: 



a) El acontecimiento tiene lugar a las 1 2:34:23.1 65439. 

b) Su origen es la maquina argos con el puerto 1 .024. Su destino es 
la maquina helios con el puerto login. 

c) El indicador S senala que es un segmento de SYN (por ejemplo, 
por un inicio de conexion). 

d) Advierte un numero de secuencia 7.838.437 y consume hasta este 
numero. Conviene observar que el tcpdump escribe el numero ini- 
cial y el final del numero de secuencia de datos, y, entre parentesis, 
la diferencia indicando la longitud del campo de datos (en este caso 
0 bytes, puesto que es un segmento de peticion de conexion). Por 
tanto, indica entre parentesis la longitud del segmento de datos. Este 
numero de secuencia es absoluto. Las salidas siguientes del tcp- 
dump indicaran los numeros de secuecia relativos al inicial. Por ejem- 
plo, en lugar de indicar 7.838.437: 7.838.450, (13) en notacion 
absoluta, indicard 1:13, (13) en notacion relativa al ISN (se cumple 
que valor absoluto es igual al ISN mas el valor relativo). Lo mismo se 
aplica a los numeros de secuencia del ACK. 

e) Advierte una ventana de 4.096 bytes. 

f) Hay una peticion de tamano maximo de segmento de 1 .024 bytes. 

La segunda Ifnea indica lo siguiente: 

a) El origen es la maquina helios con el puerto login. El destino es 
la maquina argos con el puerto 1 .023. 
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b) El indicador S senala que es un segmento de SYN (por ejemplo, 
para un inicio de conexion). 

c) Indica el numero de secuencia inicial 453.534. 

d) Reconoce con un ACK el byte siguiente que espera del transmisor, 
el 7.838.438 (es decir, 7.838.437 + 1 ), puesto que los recibio co- 
rrectamente hasta el 7.838.437). 

e) Advierte una ventana de 4.096 bytes. 

f) Hay una peticion de tamano maximo de segmento de 1 .024 bytes. 

El programa tcpdump permite escuchar, de manera sencilla, todo lo 
que sucede en la red. Admite toda una serie de indicadores para filtrar 
solo las direcciones IP de fuente o de destino que pueden interesar, o el 
tipo de protocolo que se quiere escuchar (TCP, UDP, ARP, etc.). Asimis- 
mo, admite indicadores para obtener el campo de datos, para filtrar un 
numero fi jo de segmentos, etc. Para vertodas las posibles opciones que 
permite el programa tcpdump se utiliza el comando man. 
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Anexo 3 



Notacion 

En este anexo se detalla la notacion que se utiliza en toda la unidad 
para describir los campos de los mensajes y los comandos soporta- 
dos por los diferentes protocolos. 

Cadena literal 

Las cadenas literales se definiran con letra de espaciado fi jo. 



cadena 



Variable 

Las variables se definiran con letra inclinada de espaciado fijo o letra 
cursiva. 



variable 



Alternativa 

Para indicar que en una especificacion se debe elegir un elemento 
de una lista de n elementos, se utiliza el caracter " | " para separar las 
diferentes alternativas. 



elementol I elemento2 | ... | elementon 



Repeticion 

Para los elementos que se pueden repetir entren y m veces, se utiliza la 
construccion n*mcomo prefijo. Los valores n ym se pueden suprimir. En 
este caso, se toman por defecto los valores n = Oym = vacio. 



n*melemento 

n*elemento 

*/nelemento 

*elemento 
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Software libre 



Opcional 

Para indicar que una cadena o una variable son opcionales, es pre- 
ciso cerrarlas entre los caracteres " [" y " ] 



[ elemento ] 



Repetition especifica 

Cuando se quiere indicar que un elemento debe aparecer con exactitud 
un numero entero n de veces, debe ponerse el numero n como prefijo. 



nelemento 



Lista 

Si se quiere especificar una lista de entre n y m elementos separados 
por comas, se utiliza la construccion n#m como prefijo. Los valores n 
y m se pueden suprimir. En este caso se toman los valores por defec- 
to, que son n = 0 y m = vacio. 



n#/nelemento 



Agrupamiento 

Cuando se quiere que uno o mas elementos sean tratados como un 
unico elemento a efectos de los operadores |, * y #, se indica ce- 
rrandolos con los caracteres " (" y " ) Se suele utilizar en especifica- 
ciones de repeticiones y listas. 



(elementol elemento2 ... elementos) 



Caracteres especiales 

Algunos caracteres especiales se incluyen entre los caracteres "<" y 



<CR> : 


retorno de carro (CR 


carriage 


return) 


<LF> : 


salto de linea (LF, 


line feed) 




<CRLF> 


: retorno de carro + 


salto de 


linea 
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Anexo 4 



Codigos de respuesta 

Las diferentes RFC definen los codigos de respuesta posibles para 
cada uno de sus comandos, asf como su significado. Estos codigos 
estan formados portres dfgitos y, para facilitar su interpretacion, lie- 
van asociado un significado concreto para cada dfgito. 

Primer dfgito 



Indica si la operacion se ha efectuado o no. 



Tabla 18. 




Primer dfgito 


lyz 


Respuesta preliminar: se ha iniciado la operacion y, cuando se 
haya completado, el servidor enviara una nueva respuesta. 


>- 

CN 


Operacion completada correctamente. 


CO 


Respuesta intermedia: la operacion se ha aceptado; sin 
embargo, el cliente debe enviar nuevos comandos con mas 
informacion para completarla. 


4yz 


Respuesta negativa temporal: no se puede llevar a cabo la 
operacion, pero se podra efectuar si el cliente lo reintenta. 


5yz 


Respuesta negativa definitiva: no se puede efectuar la 
operacion y probablemente tampoco se podra llevar a cabo si 
el cliente lo reintenta. 



Nota 



Cuando se quiere leer un fi- 
chero con acceso temporal- 
mente bloqueado porque 
otro proceso esta escribien- 
do datos en el mismo, el 
servidor envfa una respues- 
ta negativa temporal. En 
cambio, cuando se quiere 
leer un fichero que no exis- 
te, el servidor envfa una res- 
puesta negativa definitiva, 
aunque siempre existe la 
posibilidad de que mientras 
tanto otro proceso lo cree. 



Segundo dfgito 



Indica el tipo de respuesta. 



Tabla 19. 



Segundo dfgito 


xOz 


Error de sintaxis, comando no implementado o, en general, 
respuesta no perteneciente a ninguna de las otras categorias. 


xlz 


Respuesta informativa. 


x2z 


Respuesta referente a las conexiones. 


x3z 


Respuesta referente al proceso de autenticacion (nombre de 
usuario, contrasena, etc.). 


x5z 


Respuesta referente a la aplicacion concrete (por ejemplo, al 
sistema de ficheros o de correo). 
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ftware libre 



Tercer digito 



El tercer digito complementa la informacion del segundo digito para 
especificar de que respuesta concreta se trata. 
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GNU Free Documentation License 



GNU Free Documentation License 
Version 1.2, November 2002 

Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 

59 Temple Place, Suite 330, Boston, MA 02111-1307 USA 
Everyone is permitted to copy and distribute verbatim copies 
of this license document, but changing it is not allowed. 



0. PREAMBLE 

The purpose of this License is to make a manual, textbook, or other 
functional and useful document "free" in the sense of freedom: to 
assure everyone the effective freedom to copy and redistribute it, 
with or without modifying it, either commercially or noncommercially. 
Secondarily, this License preserves for the author and publisher a way 
to get credit for their work, while not being considered responsible 
for modifications made by others. 

This License is a kind of "copyleft", which means that derivative 
works of the document must themselves be free in the same sense. It 
complements the GNU General Public License, which is a copyleft 
license designed for free software. 

We have designed this License in order to use it for manuals for free 
software, because free software needs free documentation: a free 
program should come with manuals providing the same freedoms 
that the software does. But this License is not limited to software 
manuals; it can be used for any textual work, regardless of subject 
matter or whether it is published as a printed book. We recommend 
this License principally for works whose purpose is instruction 
or reference. 
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1 . APPLICABILITY AND DEFINITIONS 



This License applies to any manual or other work, in any medium, 
that contains a notice placed by the copyright holder saying it can be 
distributed under the terms of this License. Such a notice grants a 
world-wide, royalty-free license, unlimited in duration, to use that 
work under the conditions stated herein. The "Document", below, 
refers to any such manual or work. Any member of the public is a 
licensee, and is addressed as "you". You accept the license if you 
copy, modify or distribute the work in a way requiring permission 
under copyright law. 



A "Modified Version" of the Document means any work containing the 
Document or a portion of it, either copied verbatim, or with 
modifications and/or translated into another language. 



A "Secondary Section" is a named appendix or a front-matter section 
of the Document that deals exclusively with the relationship of the 
publishers or authors of the Document to the Document's overall 
subject (or to related matters) and contains nothing that could fall 
directly within that overall subject. (Thus, if the Document is in part a 
textbook of mathematics, a Secondary Section may not explain any 
mathematics.) The relationship could be a matter of historical 
connection with the subject or with related matters, or of legal, 
commercial, philosophical, ethical or political position regarding them. 



The "Invariant Sections" are certain Secondary Sections whose titles 
are designated, as being those of Invariant Sections, in the notice that 
says that the Document is released under this License. If a section 
does not fit the above definition of Secondary then it is not allowed to 
be designated as Invariant. The Document may contain zero 
Invariant Sections. If the Document does not identify any Invariant 
Sections then there are none. 



The "Cover Texts" are certain short passages of text that are listed, 
as Front-Cover Texts or Back-Cover Texts, in the notice that says 
that the Document is released under this License. A Front-Cover 
Text may be at most 5 words, and a Back-Cover Text may be at 
most 25 words. 
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A "Transparent" copy of the Document means a machine-readable 
copy, represented in a format whose specification is available to the 
general public, that is suitable for revising the document 
straightforwardly with generic text editors or (for images composed of 
pixels) generic paint programs or (for drawings) some widely 
available drawing editor, and that is suitable for input to text 
formatters or for automatic translation to a variety of formats suitable 
for input to text formatters. A copy made in an otherwise Transparent 
file format whose markup, or absence of markup, has been arranged 
to thwart or discourage subsequent modification by readers is not 
Transparent. 

An image format is not Transparent if used for any substantial 
amount of text. A copy that is not "Transparent" is called "Opaque". 

Examples of suitable formats for Transparent copies include plain 
ASCII without markup, Texinfo input format, LaTeX input format, 
SGML or XML using a publicly available DTD, and standard- 
conforming simple HTML, PostScript or PDF designed for human 
modification. Examples of transparent image formats include PNG, 
XCF and JPG. Opaque formats include proprietary formats that can 
be read and edited only by proprietary word processors, SGML or 
XML for which the DTD and/or processing tools are not generally 
available, and the machine-generated HTML, PostScript or PDF 
produced by some word processors for output purposes only. 

The "Title Page" means, for a printed book, the title page itself, plus 
such following pages as are needed to hold, legibly, the material this 
License requires to appear in the title page. For works in formats 
which do not have any title page as such, "Title Page" means the text 
near the most prominent appearance of the work's title, preceding the 
beginning of the body of the text. 

A section "Entitled XYZ" means a named subunit of the Document 
whose title either is precisely XYZ or contains XYZ in parentheses 
following text that translates XYZ in another language. (Here XYZ 
stands for a specific section name mentioned below, such as 
"Acknowledgements", "Dedications", "Endorsements", or "History".) To 
"Preserve the Title" of such a section when you modify the Document 
means that it remains a section "Entitled XYZ" according to this 
definition. 
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The Document may include Warranty Disclaimers next to the notice 
which states that this License applies to the Document. These 
Warranty Disclaimers are considered to be included by reference in 
this License, but only as regards disclaiming warranties: any other 
implication that these Warranty Disclaimers may have is void and has 
no effect on the meaning of this License. 



2. VERBATIM COPYING 



You may copy and distribute the Document in any medium, either 
commercially or noncommercially, provided that this License, the 
copyright notices, and the license notice saying this License applies to 
the Document are reproduced in all copies, and that you add no 
other conditions whatsoever to those of this License. You may not use 
technical measures to obstruct or control the reading or further 
copying of the copies you make or distribute. However, you may 
accept compensation in exchange for copies. If you distribute a large 
enough number of copies you must also follow the conditions in 
section 3. 



You may also lend copies, under the same conditions stated above, 
and you may publicly display copies. 



3. COPYING IN QUANTITY 



If you publish printed copies (or copies in media that commonly have 
printed covers) of the Document, numbering more than 1 00, and the 
Document's license notice requires Cover Texts, you must enclose the 
copies in covers that carry, clearly and legibly, all these Cover Texts: 
Front-Cover Texts on the front cover, and Back-Cover Texts on the 
back cover. Both covers must also clearly and legibly identify you as 
the publisher of these copies. The front cover must present the full 
title with all words of the title equally prominent and visible. You may 
add other material on the covers in addition. 
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Copying with changes limited to the covers, as long as they preserve 
the title of the Document and satisfy these conditions, can be treated 
as verbatim copying in other respects. 



If the required texts for either cover are too voluminous to fit legibly, 
you should put the first ones listed (as many as fit reasonably) on the 
actual cover, and continue the rest onto adjacent pages. 

If you publish or distribute Opaque copies of the Document 
numbering more than 100, you must either include a machine- 
readable Transparent copy along with each Opaque copy, or state in 
or with each Opaque copy a computer-network location from which 
the general network-using public has access to download using 
public-standard network protocols a complete Transparent copy of 
the Document, free of added material. 

If you use the latter option, you must take reasonably prudent steps, 
when you begin distribution of Opaque copies in quantity, to ensure 
that this Transparent copy will remain thus accessible at the stated 
location until at least one year after the last time you distribute an 
Opaque copy (directly or through your agents or retailers) of that 
edition to the public. 

It is requested, but not required, that you contact the authors of the 
Document well before redistributing any large number of copies, to 
give them a chance to provide you with an updated version of the 
Document. 



4. MODIFICATIONS 

You may copy and distribute a Modified Version of the Document 
under the conditions of sections 2 and 3 above, provided that you 
release the Modified Version under precisely this License, with the 
Modified Version filling the role of the Document, thus licensing 
distribution and modification of the Modified Version to whoever 
possesses a copy of it. In addition, you must do these things in the 
Modified Version: 

A. Use in the Title Page (and on the covers, if any) a title distinct from 
that of the Document, and from those of previous versions (which 
should, if there were any, be listed in the History section of the 
Document). You may use the same title as a previous version if the 
original publisher of that version gives permission. 
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B. List on the Title Page, as authors, one or more persons or entities 
responsible for authorship of the modifications in the Modified 
Version, together with at least five of the principal authors of the 
Document (all of its principal authors, if it has fewer than five), unless 
they release you from this requirement. 

C. State on the Title page the name of the publisher of the Modified 
Version, as the publisher. 



D. Preserve all the copyright notices of the Document. 

E. Add an appropriate copyright notice for your modifications 
adjacent to the other copyright notices. 



F. Include, immediately after the copyright notices, a license notice 
giving the public permission to use the Modified Version under the 
terms of this License, in the form shown in the Addendum below. 

G. Preserve in that license notice the full lists of Invariant Sections and 
required Cover Texts given in the Document's license notice. 



H. Include an unaltered copy of this License. 



I. Preserve the section Entitled "History", Preserve its Title, and add to 
it an item stating at least the title, year, new authors, and publisher of 
the Modified Version as given on the Title Page. If there is no section 
Entitled "History" in the Document, create one stating the title, year, 
authors, and publisher of the Document as given on its Title Page, 
then add an item describing the Modified Version as stated in the 
previous sentence. 



J. Preserve the network location, if any, given in the Document for 
public access to a Transparent copy of the Document, and likewise 
the network locations given in the Document for previous versions it 
was based on. These may be placed in the "History" section. You may 
omit a network location for a work that was published at least four 
years before the Document itself, or if the original publisher of the 
version it refers to gives permission. 
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K. For any section Entitled "Acknowledgements" or "Dedications", 
Preserve the Title of the section, and preserve in the section all the 
substance and tone of each of the contributor acknowledgements 
and/or dedications given therein. 

L. Preserve all the Invariant Sections of the Document, unaltered in 
their text and in their titles. Section numbers or the equivalent are not 
considered part of the section titles. 

M. Delete any section Entitled "Endorsements". Such a section may 
not be included in the Modified Version. 

N. Do not retitle any existing section to be Entitled "Endorsements" or 
to conflict in title with any Invariant Section. 

O. Preserve any Warranty Disclaimers. 

If the Modified Version includes new front-matter sections or 
appendices that qualify as Secondary Sections and contain no 
material copied from the Document, you may at your option 
designate some or all of these sections as invariant. To do this, add 
their titles to the list of Invariant Sections in the Modified Version's 
license notice. These titles must be distinct from any other section 
titles. 

You may add a section Entitled "Endorsements", provided it contains 
nothing but endorsements of your Modified Version by various 
parties--for example, statements of peer review or that the text has 
been approved by an organization as the authoritative definition of a 
standard. 

You may add a passage of up to five words as a Front-Cover Text, 
and a passage of up to 25 words as a Back-Cover Text, to the end of 
the list of Cover Texts in the Modified Version. Only one passage of 
Front-Cover Text and one of Back-Cover Text may be added by (or 
through arrangements made by) any one entity. If the Document 
already includes a cover text for the same cover, previously added by 
you or by arrangement made by the same entity you are acting on 
behalf of, you may not add another; but you may replace the old one, 
on explicit permission from the previous publisher that added the old 
one. 
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The author(s) and publisher(s) of the Document do not by this License 
give permission to use their names for publicity for or to assert or 
imply endorsement of any Modified Version. 



5. COMBINING DOCUMENTS 



You may combine the Document with other documents released 
under this License, under the terms defined in section 4 above for 
modified versions, provided that you include in the combination all of 
the Invariant Sections of all of the original documents, unmodified, 
and list them all as Invariant Sections of your combined work in its 
license notice, and that you preserve all their Warranty Disclaimers. 



The combined work need only contain one copy of this License, and 
multiple identical Invariant Sections may be replaced with a single 
copy. If there are multiple Invariant Sections with the same name but 
different contents, make the title of each such section unique by 
adding at the end of it, in parentheses, the name of the original 
author or publisher of that section if known, or else a unique number. 



Make the same adjustment to the section titles in the list of Invariant 
Sections in the license notice of the combined work. 



In the combination, you must combine any sections Entitled "History" 
in the various original documents, forming one section Entitled 
"History"; likewise combine any sections Entitled "Acknowledgements", 
and any sections Entitled "Dedications". You must delete all sections 
Entitled "Endorsements". 



6. COLLECTIONS OF DOCUMENTS 

You may make a collection consisting of the Document and other 
documents released under this License, and replace the individual 
copies of this License in the various documents with a single copy that 
is included in the collection, provided that you follow the rules of this 
License for verbatim copying of each of the documents in all other 
respects. 
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You may extract a single document from such a collection, and 
distribute it individually under this License, provided you insert a copy 
of this License into the extracted document, and follow this License in 
all other respects regarding verbatim copying of that document. 



7. AGGREGATION WITH INDEPENDENT WORKS 

A compilation of the Document or its derivatives with other separate 
and independent documents or works, in or on a volume of a storage 
or distribution medium, is called an "aggregate" if the copyright 
resulting from the compilation is not used to limit the legal rights of 
the compilation's users beyond what the individual works permit. 

When the Document is included in an aggregate, this License does 
not apply to the other works in the aggregate which are not 
themselves derivative works of the Document. 

If the Cover Text requirement of section 3 is applicable to these copies 
of the Document, then if the Document is less than one half of the 
entire aggregate, the Document's Cover Texts may be placed on 
covers that bracket the Document within the aggregate, or the 
electronic equivalent of covers if the Document is in electronic form. 

Otherwise they must appear on printed covers that bracket the whole 
aggregate. 



8. TRANSLATION 

Translation is considered a kind of modification, so you may 
distribute translations of the Document under the terms of section 4. 
Replacing Invariant Sections with translations requires special 
permission from their copyright holders, but you may include 
translations of some or all Invariant Sections in addition to the 
original versions of these Invariant Sections. You may include a 
translation of this License, and all the license notices in the Document, 
and any Warranty Disclaimers, provided that you also include the 
original English version of this License and the original versions of 
those notices and disclaimers. In case of a disagreement between the 
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translation and the original version of this License or a notice or 
disclaimer, the original version will prevail. 

If a section in the Document is Entitled "Acknowledgements", 
"Dedications", or "History", the requirement (section 4) to Preserve its 
Title (section 1) will typically require changing the actual title. 



9. TERMINATION 

You may not copy, modify, sublicense, or distribute the Document 
except as expressly provided for under this License. Any other attempt 
to copy, modify, sublicense or distribute the Document is void, and 
will automatically terminate your rights under this License. However, 
parties who have received copies, or rights, from you under this 
License will not have their licenses terminated so long as such parties 
remain in full compliance. 



10. FUTURE REVISIONS OF THIS LICENSE 

The Free Software Foundation may publish new, revised versions of 
the GNU Free Documentation License from time to time. Such new 
versions will be similar in spirit to the present version, but may differ 
in detail to address new problems or concerns. See http:// 
www.gnu.org/copyleft/. 

Each version of the License is given a distinguishing version number. 
If the Document specifies that a particular numbered version of this 
License "or any later version" applies to it, you have the option of 
following the terms and conditions either of that specified version or 
of any later version that has been published (not as a draft) by the 
Free Software Foundation. If the Document does not specify a version 
number of this License, you may choose any version ever published 
(not as a draft) by the Free Software Foundation. 

ADDENDUM: How to use this License for your documents 
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To use this License in a document you have written, include a copy of 
the License in the document and put the following copyright and li- 
cense notices just after the title page: 



Copyright (c) YEAR YOUR NAME. 



Permission is granted to copy, distribute and/or modify this 
document under the terms of the GNU Free Documentation License, 
Version 1 .2 or any later version published by the Free Software 
Foundation; with no Invariant Sections, no Front-Cover Texts, and no 
Back-Cover Texts. 

A copy of the license is included in the section entitled "GNU Free 
Documentation License". 

If you have Invariant Sections, Front-Cover Texts and Back-Cover 
Texts, replace the "with. ..Texts." line with this: 

with the Invariant Sections being LIST THEIR TITLES, with the Front- 
Cover Texts being LIST, and with the Back-Cover Texts being LIST. 

If you have Invariant Sections without Cover Texts, or some other 
combination of the three, merge those two alternatives to suit the 
situation. 

If your document contains nontrivial examples of program code, we 
recommend releasing these examples in parallel under your choice 
of free software license, such as the GNU General Public License, to 
permit their use in free software. 
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